⌂ YolkfolkThe Dizzy Fansite 0 logged in0 playing
Community discussion

DizzyAGE News

Started by xelanoimis on 21 January 2007 • 115,227 views

172 posts
#58620
I've updated the Dizzy colored tiles set.
There was one frame of the Dizzy walk tile, where Dizzy had one of his hands white.

You can get the updated version of the tiles set, from the official DizzyAGE site:
https://www.yolkfolk.com/dizzyage/more.html
👍 0
#58621
eh?

not quite sure what you mean there alex. tile 11 (walk) looks fine to me. his hands are white anyway.
👍 0
#58622

[quote data-userid="23" data-postid="58621"]

eh?

not quite sure what you mean there alex. tile 11 (walk) looks fine to me. his hands are white anyway.

[/quote]

erh Jamie, i think alex was on about the 'coloured' dizzy tiles with the red gloves which are available as an additional download, not the standard plain white ones that come with dizzyage {yolkfolk}:animwink:

👍 0
#58623

Yep, the coloured dizzy tiles.
I use them in my game, so that's how I noticed it :smile:

👍 0
#58768

[quote data-userid="17" data-postid="58623"]

Yep, the coloured dizzy tiles.
I use them in my game, so that’s how I noticed it :smile:

[/quote]

ahh i see.

i always use the white gloves, as that's what he had on the spectrum.

i'm curious, which do people prefer?

👍 0
#59062
DizzyAGE v2.1b available!

https://www.yolkfolk.com/dizzyage/download.html

This is a beta-testing version, for the next games coming from PTeal, Jamie and myself (with The Other Side).

It fixes the stack overflow crash (thanks Jamie) and adds a few other stuff, like F2 key for the debug console.

So, please download, use it and let me know how it performs.
(see history.txt inside)
👍 0
#59063

yippie! i can access the dev mode again {yolkfolk}:clap:

Thanks!

👍 0
#59064
...if i didn't mentioned this, in the history.txt file,

now, static brushes support the ANIM property
if it's set to 2 (loop), they play, if not, they don't and only show the frame
set in their FRAME property, that they now take advantage of.

I'll add the B_ANIM define, in the next update/version, so you can access it from script too. (this one I forgot to export in this beta). It has the same value as O_ANIM.

So, check your maps for animated static brushes and make sure they work as supposed to.
👍 0
#59065

*goes and checks map*

haha! i've got animated static brushes without even realising i had! i guess i just plonked them down, and as they worked, never thought anymore of it!

oh and btw alex, that build you sent me seems to be fine, i've played RRD continuously for over an hour a couple of times in the last few days, and didn't get any errors.

EDIT:: just noticed you've already released it! :tongue:

👍 0
#59066

the static brushes worked as animated before,
they just couldn't be stopped (with ANIM=0) :smile:

👍 0
#59193
The release of DizzyAGE v2.1 is scheduled around 3-4 february.

It is based on the current beta (v2.1b) and a few additional things,
like fixing the MusicPlay function, that currently doesn't support
the -1 value (invalid id), used to stop the current music with fade,
as the DizzyAGE v1.x did.

It will also have full support for the cause of death, having the P_DEATH
and O_DEATH exported from the engine. The O_DEATH property is now set on the #27 property and will be available in the editor too. So it will no longer be set on the first user property #32, as before. The cause of death system also includes the DeathMessage and PlayerRespawn callbacks introduced in v2.1b

So expect these changes and probably a few other small fixes...
(I had an editor crash once, while copy-pasting some brushes)
👍 0
#59196
will the O_DEATH changes and death text support affect current V2 games (i.e. RRD)?

or will it be ok as it is?
👍 0
#59197
Yes, a little bit.
Because of the redefinition of O_DEATH (from #32 to #27) you will have to:

1. remove previous definition of O_DEATH from def.gs (since it's now defined by the engine). And so do for the P_DEATH define.

2. edit the map and move the death value of your killing or hurting objects, from the first user prop, to the death prop, that will be available on the second prop page.

The change of P_DEATH define doesn't change anything, since it's used in the scripts only by value.

This should be enough for, yours and PTeal's custom death system.
(I had a quick look at yours in RailRoad.)

However you might want to have a look to the new default death system, already available in v2.1b. It is very similar to what you have, it just uses different functions, as callbacks.

There's a function PlayerDeathMessage similar to your DeathText.

The PlayerRespawn_DEATH callback is very useful to special respawns after special deaths, like when you have to move the player in a specific position after he die.

I recommend to use defines for each death (in gamedef.gs), like DEATH_RAT, DEATH_ACID, etc.

And another thing I experienced and made me adjust some scripts for TOS (and v2.1) is the situation where more than one killer code gets to write in the P_DEATH, resulting in not too exact cause of death. It's usefull to always check if P_DEATH was 0 (not specified) and/or P_LIFE is not 0 (not already dead), before you set a death in P_DEATH.

The good thing with the current death system is that you can ignore it if your game doesn't need cause of death this feature. Just don't set death properties for objects and don't change the death message callback and the default die message will appear.

Again, staying as close as possible to the default template is a good thing for both future porting of the game and for beginners trying to learn from your game.

Anyway, if you want to keep your current death code, the two changes mentioned in the beginning of the post, should be enough.
👍 0
#59198

[quote data-userid="17" data-postid="59197"]

Yes, a little bit.
Because of the redefinition of O_DEATH (from #32 to #27) you will have to:

1. remove previous definition of O_DEATH from def.gs (since it’s now defined by the engine). And so do for the P_DEATH define.

2. edit the map and move the death value of your killing or hurting objects, from the first user prop, to the death prop, that will be available on the second prop page.

The change of P_DEATH define doesn’t change anything, since it’s used in the scripts only by value.

This should be enough for, yours and PTeal’s custom death system.
(I had a quick look at yours in RailRoad.)

However you might want to have a look to the new default death system, already available in v2.1b. It is very similar to what you have, it just uses different functions, as callbacks.

There’s a function PlayerDeathMessage similar to your DeathText.

The PlayerRespawn_DEATH callback is very useful to special respawns after special deaths, like when you have to move the player in a specific position after he die.

I recommend to use defines for each death (in gamedef.gs), like DEATH_RAT, DEATH_ACID, etc.

And another thing I experienced and made me adjust some scripts for TOS (and v2.1) is the situation where more than one killer code gets to write in the P_DEATH, resulting in not too exact cause of death. It’s usefull to always check if P_DEATH was 0 (not specified) and/or P_LIFE is not 0 (not already dead), before you set a death in P_DEATH.

The good thing with the current death system is that you can ignore it if your game doesn’t need cause of death this feature. Just don’t set death properties for objects and don’t change the death message callback and the default die message will appear.

Again, staying as close as possible to the default template is a good thing for both future porting of the game and for beginners trying to learn from your game.

Anyway, if you want to keep your current death code, the two changes mentioned in the beginning of the post, should be enough.

[/quote]

yeah i probably will keep the current code, as it's less to mess around with changing, and therefore less to possibly go wrong!

👍 0
#59199
Yeah, the editor will show the death property in the second page of properties dialog.
👍 0
#59211
Found a dirty bug in the GS9 script.

This time it's the "tabdel" function, used to delete one or more elements from a table.
It somehow got through the years with a major problem, of deleting the wrong elements.

Fixed it and it will be good for you too, in the v2.1 release.

It was lucky that this evening I still worked on TOS and not started with the DizzyAGE v2.1, as planned during the day.
👍 0
#59213
i think i'll create my own little game template when you release V2.1, to include all the extra functions i use, such as the healthbar sound, and functions like the AIUpdateFly, the score, the timer, and other things like that.
👍 0
#59230
I'm thinking to add the following new feature:

-----------------------------
1. Room numeric properties.

In the ctrl+R dialog, where you can input the room's name
there will also be about 4 or 8 numeric properties (for each room)
that will work in the same way as brush properties, accessed in script
through RoomGet(rx,ry,idx) and RoomSet(rx,ry,idx,value) functions.

There's no pre-defined room properties, since the default template has no need for them,
but features like room visited (or room score), would be very easy to implement.

The only thing is that, since they get saved in the saved game, the saved game files would be a little bigger. Not a thing to worry too much. If the map is 30x30 (that's less than 1000 rooms),for 8 integers per room, we have about 1000*8*4 bytes, that's about 32KB more per saved game.

However, if someone wants it removed, he can always remove it's save/load code from the default template file.gs and keep the saved file smaller.

I think it's a useful thing. What do you think?

-----------------------------
2. Room custom text properties.

In the same room dialog (ctrl+R) there will be about 4 text inputs,
similar to the room's name, where users can enter anything they want, for each room.
These texts will be saved by the editor in a file in the map folder, similar to the one for names (dizzy.nam)

In the game scripts, there will be support for receiving these texts, in a similar way the room names are loaded, and each game, can use them as they like, filling any global structures with default info, for each room. No default storing for them and no default load and save.

Since this is a generic feature, each game will use it only if it needs it. Leaving all these input text fields blank, will result in an empty file, so no extra size, if not needed.

Being text properties, they can have whatever format the user wants. Like a list of names, or numbers.

One good use of these sort of text properties is to have, for each room, a list with sounds to play as ambient sounds (using a custom ambient sound manager). Like "torch,boil" or "drops". And this will be easy to edit from the map editor, like the room names.

I already tried something like this for ambient sounds in TOS and it's way easier than to write this file by hand, or to add code in the OpenRoom callback for each room!
I don't want to add in the map editor something too specific, so this idea with generic text room properties, would work better for everyone.

So, what do you think about this one too?
👍 0
This discussion is read-only.Browse the replies or return to the forum category.Back to forum