Dink.ini Rewrite
- Download Info
-
- Author(s): DraconicDink
- Categories: Development
- Downloads: 23
- Main
- Reviews
- Versions
- File Discussion
- Contribute
- Add a Screenshot
- Write a Review
I've have tried out ver 1.1 of this dink.ini rewrite.
There is a readme file which is pretty good - telling me about versions and ways of installing the file. It did warn me to back up my current dink.ini file before installing - which is very good, as I would not recommend using this file on any DMOD you have done a lot of work on in which you have already re-arranged graphics and their slots. (I do this a lot - for such things as grouping all the button graphics into one sequence rather than having them spread out across 4).
On opening it I was impressed with the layout and spacing. It is clear and concise.
I liked the way the unused slots were listed at the bottom.
And then I noticed a few things which I thought would create problems. The first being that some of the listed "unused" slots - were actually not free - such as this line:
//130-133
The 130 group is for the pillbug. So I thought, I'd try out the dink.ini rewrite in a small mod I keep for testing graphics and that's when I started getting problems.
I placed my alternate savebot graphics in slot 132 and my windmill graphics in slot 133. I had a pillbug on my start screen already placed so I fired up the DMOD. Pillbug would change between the 131 (direction 1) walking pillbug graphics to either a windmill or the alternate savebot.
I also discovered another unwary trap which is more specific to my test mod and the fact I had already placed a sprite with the alernate savebot graphics when they used to be in slot 194. This is not a fault of the rewrite as such - but it does mean if you have reworked the original dink.ini prior to installing this rewrite you will have some trouble shooting to do.
There are other "unused" slots which are not really free (the spike graphic sequences for one) - and they will have the same weird pillbug phenomenon if you decide to place any new graphics in any of the listed "unused" 830s or 840s slots.
This error is due to the author's lack of understanding of how sprites utilise graphics to walk and attack.
Another thing I didn't like were the listing of the SET_FRAME_SPECIAL lines right under the specific load_sequence graphics lines. I preferred the original dink.ini layout which had all the graphic load lines and then the ones that change specific attributes of each graphic.
While I like the rearrangment of lines and believe that this part of the authors objective has been achieved to a good degree, I feel this file needs more complete testing of the listed "unused" slots to see what impact they have on the game, before it should be released let alone used by anyone else.
The author's objective of maing it easier to find available spots for new graphics has not been achieved and using this file in it's current state can create problems which for any author starting out in the DMODing process will find frustrating. For this last reason I give the file a low score.
Score 4.0 out of 10
There is a readme file which is pretty good - telling me about versions and ways of installing the file. It did warn me to back up my current dink.ini file before installing - which is very good, as I would not recommend using this file on any DMOD you have done a lot of work on in which you have already re-arranged graphics and their slots. (I do this a lot - for such things as grouping all the button graphics into one sequence rather than having them spread out across 4).
On opening it I was impressed with the layout and spacing. It is clear and concise.
I liked the way the unused slots were listed at the bottom.
And then I noticed a few things which I thought would create problems. The first being that some of the listed "unused" slots - were actually not free - such as this line:
//130-133
The 130 group is for the pillbug. So I thought, I'd try out the dink.ini rewrite in a small mod I keep for testing graphics and that's when I started getting problems.
I placed my alternate savebot graphics in slot 132 and my windmill graphics in slot 133. I had a pillbug on my start screen already placed so I fired up the DMOD. Pillbug would change between the 131 (direction 1) walking pillbug graphics to either a windmill or the alternate savebot.
I also discovered another unwary trap which is more specific to my test mod and the fact I had already placed a sprite with the alernate savebot graphics when they used to be in slot 194. This is not a fault of the rewrite as such - but it does mean if you have reworked the original dink.ini prior to installing this rewrite you will have some trouble shooting to do.
There are other "unused" slots which are not really free (the spike graphic sequences for one) - and they will have the same weird pillbug phenomenon if you decide to place any new graphics in any of the listed "unused" 830s or 840s slots.
This error is due to the author's lack of understanding of how sprites utilise graphics to walk and attack.
Another thing I didn't like were the listing of the SET_FRAME_SPECIAL lines right under the specific load_sequence graphics lines. I preferred the original dink.ini layout which had all the graphic load lines and then the ones that change specific attributes of each graphic.
While I like the rearrangment of lines and believe that this part of the authors objective has been achieved to a good degree, I feel this file needs more complete testing of the listed "unused" slots to see what impact they have on the game, before it should be released let alone used by anyone else.
The author's objective of maing it easier to find available spots for new graphics has not been achieved and using this file in it's current state can create problems which for any author starting out in the DMODing process will find frustrating. For this last reason I give the file a low score.
Score 4.0 out of 10
The main problem behind the "pillbug effect" is that the engine doesn't think of sprite sequences as single numbers, it thinks of them in groups of ten.
I think it's been said before but the sequences are always held in groups of ten for any sprite where directionality changes (12346789=numpad, 5=dead or whatever, and 0=base sequence). In a perfect world, all non-directional images (inventory, houses, signs, etc) would be shoved inside the same sequence groups leaving more room for everything else.
Rule of thumb: No brain == 1, Yes brain == 10. (It gets more complex, in as much as, if I remember correctly, some brains don't use all 8 directions regardless of whether a seq is available.)
Other than that, any attempt at making Dink easier to deal with should be applauded (even if they bugger fastfiles and windowed mode...).
I think it's been said before but the sequences are always held in groups of ten for any sprite where directionality changes (12346789=numpad, 5=dead or whatever, and 0=base sequence). In a perfect world, all non-directional images (inventory, houses, signs, etc) would be shoved inside the same sequence groups leaving more room for everything else.
Rule of thumb: No brain == 1, Yes brain == 10. (It gets more complex, in as much as, if I remember correctly, some brains don't use all 8 directions regardless of whether a seq is available.)
Other than that, any attempt at making Dink easier to deal with should be applauded (even if they bugger fastfiles and windowed mode...).
this .ini rewrite aspires to be an improved version of the already perfect .ini file that comes with skeleton_s which was created by a very likable and handsome individual.
so whats different between the skeleton whatever .ini and this one anyway?
1. load sequence lines are categorized by groups with similar characteristics of the graphics being loaded.
skeleton whatever .ini is categorized in groups of tens, and arranged in ascending numerical order, in the same order that they appear in the smart cache system in dink edit.
2. grouped in categories named "buildings, walls, doors, inside, outside, dink, people, men, females, fairies, knights, gnomes, dragons, boncas, slayers, puddles, goblins, stone giants, spikes, pillbugs, animals, plants, weapons, blood, rewards, paper, fire, damage, effects, misc, menu, unused slots"
3. perhaps the most fatal flaw, claims some used up slots to be unused.
its a shame that such time was put into such a worthless file. why is it worthless? its just not practical, helpful, or better than the unorganized heap that comes with skeleton b in any way.
what would be so better about having the load sequence lines in this order? can you find what graphic is what number faster? first of all.... if you are a dink author.... all you have to do is read the screen in dinkedit to get the sprite's sequence number. why would you want to scroll through the .ini for this information?
even if you dont know how to use dinkedit, it would be much more helpful to have these categories in a collapsible form, perhaps html. then all the groups are easily navigate able. how helpful is it to have the load sequence lines grouped if you need to scroll through the whole file just to find the category first (assuming the thing you want is listed in what you are assuming it to be listed as. i, for one, consider myself a person in addition to male) then you have to scroll through the category to find the right line you needed. it just doesnt make sense.
there is no improvement over skeleton s .ini as far as i could tell. perhaps the only fallacy was that the graphics are not loaded in an order that puts things in better proximity. this is an error with the original .ini order and cannot be changed without jeopardizing compatibility. the reason behind this is obviously that the dink rpg began production before all the graphics were completed and more where added at the end of the .ini as progress went along.
the final straw is errors with the unused slots. the bottom line: just DONT USE this file. the skeleton s .ini has them in the same order as they are in dinkedit. this is the correct order. if you need to know the sequence number, just look at the screen in dink edit. if you dont know how to use dink edit you dont need to know the sequence number anyway.
SO SHOULD I DOWNLOAD IT AND TRY IT OUT? answer: not if you want to use it in a dmod. if you want to find the sequence number of a sprite without dink edit so that you can tattoo it on your ass or something, go ahead and do it. you might get the right number, but the method wont be an better, easier, or faster.
VERDICT? simonk hit the nail on the head of the problems this file has. i will take it further to say that even with certain problems fixed, it still wont serve any purpose to put the load_sequence lines in this order. to beat a dead horse, theres just no reason to have the .ini file arranged in a different way than the graphics are loaded. for those reasons i subtract another point, and that leaves us with a solid 3.
so whats different between the skeleton whatever .ini and this one anyway?
1. load sequence lines are categorized by groups with similar characteristics of the graphics being loaded.
skeleton whatever .ini is categorized in groups of tens, and arranged in ascending numerical order, in the same order that they appear in the smart cache system in dink edit.
2. grouped in categories named "buildings, walls, doors, inside, outside, dink, people, men, females, fairies, knights, gnomes, dragons, boncas, slayers, puddles, goblins, stone giants, spikes, pillbugs, animals, plants, weapons, blood, rewards, paper, fire, damage, effects, misc, menu, unused slots"
3. perhaps the most fatal flaw, claims some used up slots to be unused.
its a shame that such time was put into such a worthless file. why is it worthless? its just not practical, helpful, or better than the unorganized heap that comes with skeleton b in any way.
what would be so better about having the load sequence lines in this order? can you find what graphic is what number faster? first of all.... if you are a dink author.... all you have to do is read the screen in dinkedit to get the sprite's sequence number. why would you want to scroll through the .ini for this information?
even if you dont know how to use dinkedit, it would be much more helpful to have these categories in a collapsible form, perhaps html. then all the groups are easily navigate able. how helpful is it to have the load sequence lines grouped if you need to scroll through the whole file just to find the category first (assuming the thing you want is listed in what you are assuming it to be listed as. i, for one, consider myself a person in addition to male) then you have to scroll through the category to find the right line you needed. it just doesnt make sense.
there is no improvement over skeleton s .ini as far as i could tell. perhaps the only fallacy was that the graphics are not loaded in an order that puts things in better proximity. this is an error with the original .ini order and cannot be changed without jeopardizing compatibility. the reason behind this is obviously that the dink rpg began production before all the graphics were completed and more where added at the end of the .ini as progress went along.
the final straw is errors with the unused slots. the bottom line: just DONT USE this file. the skeleton s .ini has them in the same order as they are in dinkedit. this is the correct order. if you need to know the sequence number, just look at the screen in dink edit. if you dont know how to use dink edit you dont need to know the sequence number anyway.
SO SHOULD I DOWNLOAD IT AND TRY IT OUT? answer: not if you want to use it in a dmod. if you want to find the sequence number of a sprite without dink edit so that you can tattoo it on your ass or something, go ahead and do it. you might get the right number, but the method wont be an better, easier, or faster.
VERDICT? simonk hit the nail on the head of the problems this file has. i will take it further to say that even with certain problems fixed, it still wont serve any purpose to put the load_sequence lines in this order. to beat a dead horse, theres just no reason to have the .ini file arranged in a different way than the graphics are loaded. for those reasons i subtract another point, and that leaves us with a solid 3.
Well I tried this rewrite. This is what I thought.
Good: I found that it does look good with the organized structure.
spacing was good, and concept was one of the better ones out there.
Bad: The unused numbers are all not true. By the time I got various parts
for story, graphics, tiles and sound placed in the dmod. It took about 1 hour before I could get just one graphic to show up right.
some numbers from the unused section did not work, mostly most of them.
I made 4 screens, then started to add in the 850+ section. I got only
three placements. Then it was impossible to add others.
Total time spent was 8 hours to make it work. Finally I just dropped it.
Since then I have deleted the work.
Good try Draconic Dink though, and got a B for effort on this one.
Maybe you can look into it more and refine it. I will try it again.
Note for the future of this project. Please include all the files needed
to start right out with the project; simular to the skelton B. Some of those other files need some touch up also.
respectfully submitted
hance (Matt)
Good: I found that it does look good with the organized structure.
spacing was good, and concept was one of the better ones out there.
Bad: The unused numbers are all not true. By the time I got various parts
for story, graphics, tiles and sound placed in the dmod. It took about 1 hour before I could get just one graphic to show up right.
some numbers from the unused section did not work, mostly most of them.
I made 4 screens, then started to add in the 850+ section. I got only
three placements. Then it was impossible to add others.
Total time spent was 8 hours to make it work. Finally I just dropped it.
Since then I have deleted the work.
Good try Draconic Dink though, and got a B for effort on this one.
Maybe you can look into it more and refine it. I will try it again.
Note for the future of this project. Please include all the files needed
to start right out with the project; simular to the skelton B. Some of those other files need some touch up also.
respectfully submitted
hance (Matt)
