The Dink Network

Reply to Re: Easy DinkC beta testing

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:
 
 
January 13th 2008, 03:58 PM
custom_magicman.gif
magicman
Peasant They/Them Netherlands duck
Mmmm, pizza. 
To start with, variables could be annotated variables with a type. Technically, they're all integers, but their semantics can be different. For example, something like this:

int &sound = playsound(arguments here)
sp_hitpoints(&sound,5);

isn't going to make sense. &sound will be a "Sound number", while sp_hitpoints expects an "Active sprite number". This will also prevent errors like the following to be made:

editor_seq(&current_sprite,5);

What's wrong? &current_sprite is an "Active sprite number", while editor_seq expects an "Editor sprite number".

And of course, you can go wild with these variable types. "Frame number"s and "Sequence number"s come to mind. The program could even check if a certain "Frame number" variable ever exceeds 50, and give a warning based on that.

Suggesting functions is just like it's shown in the screenshot, but not hardcoded as it's now, and with every function, not just the say family.

And it'd be nice to have additional info in the list of suggestions, using these types, like:
say_stop(string[199], active sprite number)
say_xy(string[199], x-coord, y-coord)
say_stop_xy(string[199], x-coord, y-coord)
say_stop_npc(string[199], active sprite number)

But I guess this wouldn't be too difficult once the backend is set up.