The Dink Network

Reply to Re: Dance party, dancing by myself backwards

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:
 
 
April 7th, 10:03 PM
custom_simon.gif
SimonK
Peasant He/Him Australia
 
Yes, that thing with it occasionally missing Dink and flying backwards is because sometimes it doesn't return on hitting hardness/hard sprites, but then it does and goes past Dink, even when it shouldn't. Not sure exactly which part of the process is causing it as item-hot.c throws the hammer, dam-ham is in charge of the returning about 700 ms, and then dam-ham2 handles what happens when the hammer hits something, which is also part the returning thing. And then there is a spawned script as a safety backup - 2seckill.c - to kill both the hammer and it's shadow if the other scripts don't. I did this because I found sometimes the hammer would get stuck in hardness.

So while the hammer returning is not error free yet, it is the most functional it's been, and that occasional error of going past Dink doesn't always happen. I think it is achieving more of what I'm after than having the hammer disappear when it hits hardness which is what the boomerang scripts it is based on does.

Yes, your solution for modifying the starting position of the hammer sprite to be beyond the hit range of Dink's hit frame is more elegant than changing the set_frame_special value from 1 to 0 on arming the weapon and then back to 1 when disarming - at least with freedink and YeOldeToast dink, I had already gone down the path of mucking around with that way of removing the punch sound. I'm curious why the DinkHD engine achieves the end result by using the single set of
	//removing which frame can 'hit'
	init("set_frame_special 102 3 0");
	init("set_frame_special 104 3 0");
	init("set_frame_special 106 3 0");
	init("set_frame_special 108 3 0");


which to me makes sense based on the information about the init() command in the DinkC Ref.

but YeOldeToast dink engine requires a second occurrence of those lines, which I've now added into the armmovie procedure of item-hot.c and freedink requires a third occurrence of those same lines, which I now repeat twice in the arm procedure. And doing this removes the punch sound in all three engines. Messy and not as elegant as just changing the starting co-ordinate of the hammer sprite to be outisde Dink's hardbox for the hit frame. Oh well... And then if you load, unload, reload, or even reload the hammer twice in the weapon selection screen that also seems to remove the punch with one instance of those init() lines above, at least in YeOldeDink or freedink, I can't remember which one.

I haven't tested this in the original dink.exe engine yet or RTDink web-based one.

So I have a ver 3.03 of the redux standing by, but I've probably wait a few days for other bugs to be found. I already found one myself with the bonca farmer in Story 3 not responding to being hit with the Hammer of Truth, as well as a missing kill_this_task() command from a spawned script - one that loads the correct coloured scorpion for Story 7. I also noticed if you call save games anything other than save[n].dat then Dfarc 3.0 will include them in the packaging, so besides the nonzip file, I'll include xsave2.dat to xsave7.dat in the next release. It would be nice to have the option to include save.dat files, but I can understand the default of removing them.

Of course Dfarc3 doesn't remove the DinkHD saved games of autosave, autosaveb, quicksave and continue-state dat files.