Wish List

With the upcoming changes to the Dagon engine (and now that Agustin’s back from GamesCon :P), I thought that I’d start another wish list. Please feel free to add or correct. :slight_smile:

To start, here’s a list of wished for features and “fixes” that we need for problems, which we’ve encountered while trying to create our game. (Sorry, Agustin, I could not figure out how to add these to the list on GitHub! :-[ :retard: ) –

  1. Going from a slide to a node using a switch locks the camera as though it is still in a slide. This a high priority for us as locking up the camera prevents progress in the game.

Example:

[code]–slide
inShip_LidDown_Detail = Slide(“still_CanopyDown.png”, “seated in ship with canopy closed”, true)

–push button to start trip
goToAdamantus = inShip_LidDown_Detail:addSpot( Spot({368, 921, 580, 921, 580, 1157, 368, 1157}) )
goToAdamantus:attach(FUNCTION,
function()
play(“GateHum.ogg”, {loop = true})
goPortal:enable()
goPortal:play()
goPortal:stop()
switch(City)
switch(City1)
end)
goToAdamantus:enable() [/code]

Example using onReturn:

[code]locker1OpenDetail = Slide(“still_n4W_Locker1Open.png”, “Lockers”, true)
locker1OpenDetail:onReturn(
function()
play(“locker_close.ogg”)
end)

locker1Return = locker1OpenDetail:addSpot( Spot({0, 700, 1920, 700, 1920, 1200, 0, 1200}) )
locker1Return:attach(FUNCTION,
function()
switch(SSCryo)
switch(SSCryo4)
lookAt(270, 0, true)
end)
locker1Return:setCursor(BACKWARD)[/code]

  1. Video patches on spots are off color.

  2. Custom cursors are needed (especially for inventory items).

  3. More control is needed during transitions. Right now, switch is accompanied by the sound of footsteps, incremental camera movement, and a view of the starting node just before the actual switch to the destination node. If I understand what’s already been done, the first two will be able to be eliminated with the newly added parameter, true. The last flickering of the starting place, however, remains.

  4. Would like to be able to use fadeIn and fadeOut on nodes and slides as well as on overlays. For instance, we have a force field that should disappear gradually instead of instantly. We could do this with a video, but fadeOut would be much easier and would require less assets.

  5. Would like to be able to use video patches on spots on an overlay.

  6. To prevent freezing, I need a way to disable other overlays when a new overlay is opened. Related to this, when spots on a node that lie “beneath” an opened overlay – and which also open an overlay – are inadvertently clicked, it can cause the overlays to lock-up.

  7. Camera turns using lookAt are not very precise. (I think one of the fixes listed on GitHub might have already corrected this for an upcoming version of Dagon?)

I can’t really add much, most of the things I’m encountering are bugs, ie the problem with effects and showing spots and using images rather than tex which I assume will be fixed/changed now anyway

Got it, we talked about most of these already. I will fix #1 ASAP because it’s straightforward, then look into the rest. Expect a brand new engine version soon – it might break some things, but overall the improvements are quite drastic.

Nige, what sort of effects/spots bugs you mean?

Check this thread mate
If you have show spots enabled and effects turned off everything turns dark blue

Cleo, I have the first request (and the most critical one) ready for you. I will work on 4th and then 8th next. The rest will require a bit of polishing first but they’re on my list of priorities as well.

The fix will be included in Dagon 0.6.1. Note that I’m using a more strict and logical versioning system now: https://github.com/Senscape/Dagon/releases

0.6.1 won’t be a release but I will upload a Windows binary for you tomorrow right here!

Very exciting news, Agustin. I’ll keep an eye out for 0.6.1. :clapping:

Cleo, regarding no. 5, what did you exactly have in mind for this? I understand the need to fade overlays, but nodes and slides not so much. Dagon currently allows fading nodes in and out (it’s actually done in the teaser) but this is only useful in very few cases.

You see, the engine only allows loading one node or slide at a time, and this is something that won’t change anytime soon. So the only possible reason to fade nodes/slides would be to fade the whole scene from or to black – is that what you meant?

And here it is, 0.6.1 fixing this issue: Manually switching from a slide to a room or node locks up the game · Issue #90 · Senscape/Dagon · GitHub :slight_smile:


dagon-0.6.1-win32.zip (1.3 MB)

Got it! Thanks, Agustin. Can’t wait to try it out. :slight_smile:

[quote=“Agustín, post:7, topic:616”]Cleo, regarding no. 5, what did you exactly have in mind for this? I understand the need to fade overlays, but nodes and slides not so much. Dagon currently allows fading nodes in and out (it’s actually done in the teaser) but this is only useful in very few cases.

You see, the engine only allows loading one node or slide at a time, and this is something that won’t change anytime soon. So the only possible reason to fade nodes/slides would be to fade the whole scene from or to black – is that what you meant?[/quote]

I don’t know why others might want FadeIn/FadeOut of nodes, but I’d like to see that feature because I’m cheap like that. I like to just go Fade Out the screen for certain actions of the player like, if the character is going to have breakfast, I like to just fade out the screen to black, put some noises in it and fade in again to finish the scene. Animating all that would be too painful, but that’s just me.

I can’t really request a feature that won’t be used in Asylum or in any other games that are made in Dagon in that matter. I can just say it’d make some lives easier, but if you say “just do it properly you cheapster”, I have no answer :smiley:

You said it is possible to do it, but I couldn’t figure out how to do it and it’s driving me crazy.

I just tested this and it works fine:

node = currentNode() node:fadeOut() node:fadeIn()

What I meant is that it probably doesn’t make much sense to fade in/out individual nodes or slides, but maybe the whole scene. Something like this:

scene.fadeOut()

And provide other ways to manipulate the whole scene or view. Anyway, for now maybe it’s OK to use the previous code to do fancy fadeouts/ins :slight_smile:

wow, that was simple. So what I want is already implemented. Let’s move on :-[

Simplicity is one of Dagon’s cornerstones :wink:

Ah, sorry. In my excitement about the new engine release I did not see Agustin’s post about item #5. I probably should have said that we’d like to used fadeIn and fadeout on “a spot that is not on an overlay.”

Here’s an example of when we’d like to use fadeOut. We have a forcefield-like object. The forcefield image is contained in a spot on a face of the node. When clicked, we’d like the forcefield to seem to dissolve. I’ve been unable to use fadeIn and fadeout in order to get the image to disable. So it seems that the code works fine on an overlay, but not on a node.

I hope this is clear.

Ah, OK. Crystal clear. Yes, I think I can do that :nod:

Thanks, Agustin!

A little report:
Using version 0.6.1 and the new configuration file on Windows 7 - 32bit, all of my old files including the TEX files for the nodes worked great. With the debugger running, I did get a warning “Creating objects in runtime is not recommended: Readme” whenever an overlay opened. Also, I was used to the old camera movement and had to switch to “SLOW camera” in order to keep the camera movement from being too jerky or spinning.

And with this version, I am no longer stuck in a slide when trying to move to another node or when using onReturn :thumbsup:.

I’d like to run the game with fov 62 to keep things from looking claustrophobic, but then the edges of my videos show. This is true even if I stretch them to the full width of the cube face. Is there any work around for this?

Ah yes, pay no attention that warning – it’s unnecessary and will be removed.

Regarding the videos showing, we’re also encountering the same problem. I’m going to provide a simple workaround for this: lookAt will optionally increase the FOV, just a bit. This is particularly useful when focusing on doors, as it also makes sense that the character “approaches” to open it. I’m hoping it will do the trick (of course, another workaround, but not as efficient, is to create bigger videos).

Please, report back any crashes that you encounter! :slight_smile:

Agustin, Even if I stretch the video to the full width of the node side, it’s still too small when I change the FOV to anything higher than 55. If there’s a way to position the video so that it exceeds the width of the side of the node (2048 pixels wide), I don’t know how to do that.

Ah OK, I thought you meant that you’re seeing the vertical borders of the video. I’ve created an issue for this: https://github.com/Senscape/Dagon/issues/81

For a “travel” video, I did try changing the fov as the video was launched and then back again as you enter the destination node and it worked great if I stretched the video.

[code]Gondola_ride_to_Mansion = City12c:addSpot( Spot(NORTH, {0, 448, 2047, 448, 2047, 1599, 0, 1599}, {sync = true}) ) – for a 1920 x 1080 video
Gondola_ride_to_Mansion:attach(AUDIO, “Gondola_12c-13a.ogg” )
Gondola_ride_to_Mansion:attach(VIDEO, “gondola_City12c_City13a.ogv” )
Gondola_ride_to_Mansion:disable()

–**add the spot on 12c to ride to the Mansion
GoStick = City12c:addSpot( Spot(NORTH, {905, 1882, 1055, 1882, 1055, 2047, 905, 2047}) )
GoStick:attach(FUNCTION,
function()
self:setCursor(USE)
lookAt(0, 0, true) --look at GoStick
camera.fov = 55
Gondola_ride_to_Mansion:enable()
Gondola_ride_to_Mansion:play()
Gondola_ride_to_Mansion:stop()
switch(CitySouth)
switch(CitySouth13a)
lookAt(45, 0, true)
camera.fov = 63
end) [/code]

This video is 1280 x 720 and will also fill the screen with coordinates -( Spot(NORTH, {64, 484, 1983, 484, 1983, 1563, 64, 1583}, {sync = true}) ) , but the upper and lower edges sometimes bob into view. I would not recommend using this size.

I need to experiment with stretching the video to a median size.

Also, just FYI, these are the coordinates that I was using to stretch the videos to the max -

( Spot(NORTH, {0, 384, 2047, 384, 2047, 1663, 0, 1663}, {sync = true}) ) – for a 1920 x 1200 video

( Spot(NORTH, {0, 448, 2047, 448, 2047, 1599, 0, 1599}, {sync = true}) ) – for a 1920 x 1080 video