The Dink Network

I'm playing around with an experimental type of dmod, and I'm just wondering... I know that dinkc supports only integers, but has anyone figured out how to store any other information type? Like int tuples, triples or something? I might even need lists of these tuples triples. I know SlipDink has released checkbit, but I'm unsure how that will fit my purpose yet. If it can at all.

You could use editor_seq as makeshift array. You have just to make sure that you use editor numbers from a screen where it's not used for other purposes, so it won't conflict with anything else.

For other information types, fixed-point numbers are rather trivial to implement, and I think you could do floats if you had way too much time to handle. And since you have arrays with editor_seq and editor_frame, you could do strings, although you can't use them for say()-series functions, so there's not much point.

One of my million unfinished projects is implementing a scripting language that transpiles to DinkC, which would have fixed-point type; among other niceties such as macros, constants and compilation-time error-checking.

I'm not sure I fully understood you regarding editor_seq

editor_seq - can store integers of value between 0 and 65535, so there appears to be a binary relationship there, with that top value being an unsigned integer equivalent or some such thing, I'm way out of my depth here.

editor_frame - can store integers of value between 0 and 255, another binary thing I suspect, as it is 11111111 in the land of 0s and 1s.

So with each unused map screen having 99 sprite slots available to store 2 values, you've got 99 tuples available, with either 255 or 65535 possible values of the, switcheroos... I guess... my attempts at python programming are long behind me...

Or you could store a variable that holds 2 values by using a multiplication factor of 100 or 1000 of the first value and using math_mod operation in DinkC.

I've consider using this to store attributes of sprites such as the x and y coordinates they have died on, but stopped once I realised that the limit was 65535, as I would've like to do 1000s for the x and the mod or remainder for the y. (x, y) co-ordinates would become x*1000 + y.
&pos = sp_x(&current_sprite, -1);
&pos *= 1000;
&spy = sp_y(&current_sprite, -1);
&pos += &spy;

Then use math_mod and a divisor of 1000 to retrieve y coord from &pos, and then divide &pos by 1000 to get x coord... ho hum... I'm rambling...

Easier to use editor_seq for x coord, and halve y coord and store it in editor_frame, and just double it upon retrieval.

Ah... understood. I wanted to do something similar for smaller subquests where "subquest_story" variable would require max value of 4 or something. Checkbit does exactly that. But uhm... Nah, that doesn't help me. I need a record type for what I want to do, and that's way out of DinkC league.

I meant that you can use editor_seq with the sprite number as array index and sequence as value, so you can do something like this

//Switch to screen holding the array
int &old_map = &player_map;
&player_map = 123;
//Store 10 numbers to an array
int &index = 1;
int &value = 1;
loop:
&value *= 2;
editor_seq(&index, &value);

&index += 1;
if(&index < 11)
{
    goto loop;
}

&player_map = &old_map;
//Now we effectively have an array of [2, 4, 8, 16, 32, 64, 128, 256, 512, 1024]

You can retrieve values by editor_seq(&index, -1), like this:

freeze(1);
int &old_map = &player_map;
&player_map = 123;
int &index = 1;
int &value;

loop:
&value = editor_seq(&index, -1);
say_stop("The value at index &index is &value", 1);
&index += 1;
if(&index < 11)
{
	goto loop;
}

&player_map = &old_map;
unfreeze(1);

edit: fixed the &value increment

edit2: forgot that editor sprite numbers start from 1

edit3: added the value readback script

Tip, you can use screen 0.

Which is un-editable in any of the editors, but still stores 99 sprites editor info values for editor_seq and editor_frame, and it saves and loads in the save file.

wouldn't this just be the value 1 stored multiple times?

Oops, you're right.
Fixed, though the basic idea was hopefully clear anyway

Huh... Combined with checkbit, I think it's possible to make a map structure out of it.

Working with &player_map is kinda buggy affair. I has an intro script:

    fade_up();
    sp_nodraw(1, 1);
    wait(1);
    freeze(1);
    dink_can_walk_off_screen(1);

    // doing stuff with editor seq
    int &old_map = &player_map;
    &player_map = 0;
    editor_seq(0, 26);
    editor_seq(1, 26);
    editor_seq(2, 15);
    editor_seq(3, 29);

    &player_map = 1;
    editor_seq(0, 1);
    editor_seq(1, 1);
    editor_seq(2, 1);
    editor_seq(3, 1);

    &player_map = &old_map;
    
    // intro blah blah

    fade_down();
    &player_map = 197;
    script_attach(1000);
    load_screen();
    draw_screen();
    freeze(1);
    fade_up();

For some reason, &player_map ends up having value of 0. If I force it one more time to be 197 after last script attach, walking to another screen on occasion throws you at screen 1 (meaning it's still set to 0)

Sometimes that can happen if the starting screen's not set properly, or when mode isn't set to 2 at start.

Also is editor sprite 0 a thing... I thought it started at 1.

Yeh pretty sure editor_seq(0, 26); won't do anything... I'm sure the editor sprite range is 1-99.

Ah, I had completely forgotten about that, fixed the example script again... and now I actually tested that it works.

Edit: Technically editor sprite 0 does exist, as values corresponding to editor_(seq/frame/type) are declared as "unsigned (short/char/char)[100]" in the source, you just can't use them in any way.

Might be useful to update DinkC reference?

The reference alredy says that the editor sprite range is 1-99.

Uhm... I don't see it here. Maybe in text version it's present.

Uhm... I don't see it here. Maybe in text version it's present.

Variable Types

Uh, yeah, but it's kind of spread out information. Might be worth adding it to that other component specifically for editor_seq as well.

I'm aware some people here know DinkC by heart, but the rest of us...

Hmm.. not sure that would be very consistent, because then it would only make sense to repeat all the other variable types in every function they apply to as well, which would get very messy for a reference.

The purpose of the functions is a simple reference and exaplanation to what they do. The guides section should really be read to get a complete overview of the workings of DinkC as well.

True. That'd be a lot of work. Maybe just rename them in the table from Editor sprite to editor_sprite? I realize this is nitpicking, I probably wouldn't connect the dots by myself in any case.