where did Element Properties go?

Discussion around programming R'n'D, its source code and its tools.

Moderators: Zomis, Flumminator

filbo
Posts: 308
Joined: Fri Jun 20, 2014 10:06 am

where did Element Properties go?

Post by filbo » Fri Feb 06, 2015 5:52 am

I pulled latest changes from git, and now the '?' button in the editor just prints "::: zoom button pressed with mouse button 1" (or 2 or 3).

I see in the change log "moved element properties button in editor to more prominent position", but I don't see a new button -- quite un-prominent!

Graphics elements for the change not checked in yet maybe?

filbo
Posts: 308
Joined: Fri Jun 20, 2014 10:06 am

Re: where did Element Properties go?

Post by filbo » Fri Feb 06, 2015 5:52 am

("zoom button" is somewhat intriguing, but doesn't seem to actually do anything... ?)

User avatar
Holger
Site Admin
Posts: 2977
Joined: Fri Jun 18, 2004 4:13 pm
Location: Germany
Contact:

Re: where did Element Properties go?

Post by Holger » Fri Feb 06, 2015 7:55 am

Sorry, you're right -- the problem is, that the git repository really only contains the source code files, but not the game artwork. As I am relatively new to git, I'm not sure yet if it would be a good idea to add lots of binary file to the repository (even if they are relatively small), as I cannot oversee the long-term consequences at the moment (repository size over time, speed of changing branches, potential problems when merging branches, just to name a few potential headaches).

So for now, please find the changed graphic as attached.

Regarding the new "zoom" button: It's intended functionality is not yet implemented, but it should be used for zooming the level playfield in the editor, mainly to be able to get a quick overview over the level by using 8x8 or 4x4 tiles instead of 16x16 tiles (and maybe also the other direction, being able to edit the level using 32x32 tiles (or larger, if the artwork set supports it)).
Attachments
RocksDoor.png
updated file "RocksDoor.png"
RocksDoor.png (19.08 KiB) Viewed 8774 times

User avatar
Holger
Site Admin
Posts: 2977
Joined: Fri Jun 18, 2004 4:13 pm
Location: Germany
Contact:

Re: where did Element Properties go?

Post by Holger » Fri Feb 06, 2015 7:59 am

BTW: Don't be confused about the _two_ new buttons in that graphic file ("PROPERTIES" and "ELEMENT CONFIG"). I was trying out both as the new "element properties" button, but so far decided to use the "PROPERTIES" variant over the other one.

filbo
Posts: 308
Joined: Fri Jun 20, 2014 10:06 am

Re: where did Element Properties go?

Post by filbo » Fri Feb 06, 2015 10:33 am

If I install that as /usr/share/games/rocksndiamonds/graphics/gfx_classic/RocksDoor.png will it interfere with operation / appearance of RnD binaries less than a few hours old?

User avatar
Holger
Site Admin
Posts: 2977
Joined: Fri Jun 18, 2004 4:13 pm
Location: Germany
Contact:

Re: where did Element Properties go?

Post by Holger » Fri Feb 06, 2015 10:41 am

No, this graphical change is backwards compatible to older (release and development/git) version of R'n'D. (It will currently not interfere with any release version anyway, as they use PCX files, while the new 4.0.0.0 development versions use PNG files.)

Nevertheless, I would generally recommend to use a different directory for trying out development versions if you also want to have a stable/release version installed on the same system in parallel.

filbo
Posts: 308
Joined: Fri Jun 20, 2014 10:06 am

Re: where did Element Properties go?

Post by filbo » Fri Feb 06, 2015 10:47 am

Well, that's rather confusing! I put the file in place. New RnD binary still shows old graphics with '?' in the "Zoom" slot and no "Properties" button. But `strace` confirms that it is opening just one RocksDoor.p* file, which is the new one with no '?' graphic. ?!?

Now that I know where to look, hovering the mouse where the "Properties" button ought to be gives tooltip "PROPERTIES OF DRAWING ELEMENT ('P')"; clicking it works.

(Small bug noted: put mouse on "Properties" button, visible or not; keeping mouse completely steady through the sequence, click it and then hit ESC. Notice that after ESC, the tooltip does not return. Now click again; "properties" UI is activated again, showing mouse was in the right place; and if you watch carefully you'll notice that the tooltip appears for a moment, *after* the click).

User avatar
Holger
Site Admin
Posts: 2977
Joined: Fri Jun 18, 2004 4:13 pm
Location: Germany
Contact:

Re: where did Element Properties go?

Post by Holger » Tue Feb 10, 2015 2:23 pm

> Well, that's rather confusing! I put the file in place. New RnD binary still shows old graphics with '?' in the "Zoom" slot and no
> "Properties" button. But `strace` confirms that it is opening just one RocksDoor.p* file, which is the new one with no '?'
> graphic. ?!?

This sounds really strange (especially as you've extra-checked using 'strace'). I have no idea how the old "?" button can be displayed if the corresponding artwork file is never loaded -- very confusing. :-o

I think I have come to the conclusion that I will extend the git repository to not only contain the program's C source code (and maybe some shell scripts), but also all other files required to build the complete game package, especially the graphics, sounds and music artwork. As R'n'D is a retro game with retro style artwork in its base package, those (relatively small-sized) binary files won't blow up the git repository too much. The advantage would be a git repository that could be used to build a running game inside its directory, without the need to add any extra files (especially as it is not always sufficient to just use the files from the last stable release package, as can be seen in this case).

I know that storing binary files in a git repository is considered harmful by some (though not by others) -- git experts, feel free to let me know what you think about it (or what might be the "right" way to do it).

> (Small bug noted: put mouse on "Properties" button, visible or not; keeping mouse completely steady through the sequence,
> click it and then hit ESC. Notice that after ESC, the tooltip does not return. Now click again; "properties" UI is activated
> again, showing mouse was in the right place; and if you watch carefully you'll notice that the tooltip appears for a
> moment, *after* the click).

In fact, this is intended behaviour: The tooltip is displayed on any mouse activity while the mouse cursor is over the gadget, which is the case here when clicking the gadget the second time (if you keep the button pressed for a moment before releasing it, you will notice that the "properties" tooltip will be printed by the clicking, while it will only be overwritten by the following tooltip when the mouse button is released (which happens because the "draw single items" radio button gets activated programmatically when switching to the "properties" screen, just as it would have been pressed manually). But maybe it is not consistent (or does not appear to be consistent to the user) in all cases... :-/

filbo
Posts: 308
Joined: Fri Jun 20, 2014 10:06 am

Re: where did Element Properties go?

Post by filbo » Wed Feb 11, 2015 5:31 am

The tooltip is displayed on any mouse activity while the mouse cursor is over the gadget, which is the case here when clicking the gadget the second time (if you keep the button pressed for a moment before releasing it, you will notice that the "properties" tooltip will be printed by the clicking, while it will only be overwritten by the following tooltip when the mouse button is released (which happens because the "draw single items" radio button gets activated programmatically when switching to the "properties" screen, just as it would have been pressed manually). But maybe it is not consistent (or does not appear to be consistent to the user) in all cases... :-/
Indeed, does not appear or feel consistent. The game has redrawn the screen (and corresponding semantic context) underneath the mouse. In so doing, even though I haven't moved the mouse, its relationship with the hovered context has changed and the system should act as if the mouse was moved.

I have other not-updating issues with the game that I intend to slowly bring up as I am able to properly articulate them. The one that imediately comes to mind is that score, #emeralds and #dynamite (and probably other things like keys-in-possession) do not update during fastest visible playback mode ("warp"?). (This is a long-time issue.)

Meanwhile, one other thing I noticed with latest code out of git (well, 2 days old now, have not tried to sync since then): in Level Creator, in the long scrollable list of elements, the section toggles do not appear. The set of open sections is equivalent to <players> <txt> <txt> <ce> <ge> <ref> <use>, and there doesn't seem to be anything I can do about it.

User avatar
Holger
Site Admin
Posts: 2977
Joined: Fri Jun 18, 2004 4:13 pm
Location: Germany
Contact:

Re: where did Element Properties go?

Post by Holger » Wed Feb 11, 2015 8:11 pm

> Indeed, does not appear or feel consistent. The game has redrawn the screen (and corresponding semantic context)
> underneath the mouse. In so doing, even though I haven't moved the mouse, its relationship with the hovered context has
> changed and the system should act as if the mouse was moved.

Sounds reasonable. As the drawing of tooltips gets triggered by mouse events over gadgets, this would have to be added somehow in such "context switch under mouse pointer" situations...

> I have other not-updating issues with the game that I intend to slowly bring up as I am able to properly articulate them. The
> one that imediately comes to mind is that score, #emeralds and #dynamite (and probably other things like keys-in-possession)
> do not update during fastest visible playback mode ("warp"?). (This is a long-time issue.)

Fixed. (See latest updates in git, just pushed.)

> Meanwhile, one other thing I noticed with latest code out of git (well, 2 days old now, have not tried to sync since then):
> in Level Creator, in the long scrollable list of elements, the section toggles do not appear. The set of open sections is
> equivalent to <players> <txt> <txt> <ce> <ge> <ref> <use>, and there doesn't seem to be anything I can do about it.

This is most probably due to commit a5d330d5 ("re-enabled editor palette element options in setup configuration file") and has to do with the value of the following configuration options in your "setup.conf" file:

--- snip ---
editor.el_boulderdash: on
editor.el_emerald_mine: on
editor.el_emerald_mine_club: on
editor.el_more: on
editor.el_sokoban: on
editor.el_supaplex: on
editor.el_diamond_caves: on
editor.el_dx_boulderdash: on
editor.el_headlines: on
--- snip ---

They are most probably set to "off" for whatever reason (not sure why, because they are set to the default value "on" if they do not exist and the setup options are saved). They were ignored before (being introduced and deactivated again a log time ago (once they could be set in the setup menu directly, but nobody seemed to need them)). As Juergen Bonhagen (the author of "R'n'D jue") recently needed them again for convenience, I re-activated them again (but only accessible by editing in the "setup.conf" file directly). I wonder if others would have similar problems due to this change...

filbo
Posts: 308
Joined: Fri Jun 20, 2014 10:06 am

Re: where did Element Properties go?

Post by filbo » Thu Feb 12, 2015 5:22 am

> As the drawing of tooltips gets triggered by mouse events over gadgets, this would have to be
> added somehow in such "context switch under mouse pointer" situations...

Inject a synthetic "mouse moved 0 pixels" event on major redraws or UI context shifts?

>> score, #emeralds and #dynamite do not update during fastest visible playback mode ("warp"?)

> Fixed. (See latest updates in git, just pushed.)

Pulled, works... Thanks!

>> in Level Creator, in the long scrollable list of elements, the section toggles do not appear.

> This is most probably due to commit a5d330d5 ("re-enabled editor palette element options
> in setup configuration file") and has to do with the value of the following configuration
> options in your "setup.conf" file:

Indeed, turning all of those on fixed it. I didn't check, but I guess editor.el_headlines is the one
that enables the section toggle controls?

> They are most probably set to "off" for whatever reason (not sure why, because they are set
> to the default value "on" if they do not exist and the setup options are saved)

No idea why, but they were indeed set to "off".

My setup.conf is tagged "ROCKSNDIAMONDS_SETUP_FILE_VERSION_3.3", maybe force them on and
increment the version number?

I also saw "editor.el_by_game" and "editor.el_by_type"; from the source it looks like these
are disabled / don't do anything -- what's the plan? </monkey>

filbo
Posts: 308
Joined: Fri Jun 20, 2014 10:06 am

Re: where did Element Properties go?

Post by filbo » Thu Feb 12, 2015 9:03 am

"warp forward" (Play, Eject) has the same problem. Play a level half-way, hit ESC, replay to that
point with non-playfield-drawing "warp forward". Game pauses with the final frame of action,
but everything in the score part of the display is as it was before starting replay.

(Hit Record to continue playing from that point...)

filbo
Posts: 308
Joined: Fri Jun 20, 2014 10:06 am

Re: where did Element Properties go?

Post by filbo » Mon Mar 23, 2015 8:14 am

I finally noticed: this problem occurs with some levelsets and not with others. I think it might be levels using the EMC engine vs. RnD engine.

I noticed because I was playing through the EMC-engine-tagged set of BD4 levels and wanted to compare behavior in one case to the RnD level. Looking at these two levels specifically:

/usr/share/games/rocksndiamonds/levels/DX-Boulderdash/dx_bd4/047.level
/usr/share/games/rocksndiamonds/levels/Emerald Mine Club/emc_bd4/47S

I see these disparities (circled in green for good / red for bad -- plus your copyright out of date):
bd4.png
bd4.png (27.27 KiB) Viewed 8272 times
(*) The question I was asking was: does horizontal wraparound work in either engine? A: no, neither.

Also, level 42 in both sets is unwinnable because the amoeba grows way too fast. At least I think that's the problem. The RnD level has some tweaks (extra exits on the right side of the amoeba room) which would allow it to be won -- if there was a way to dig through the steel wall, but there isn't. Changing one block of that wall to diggable wall (so you could drop one of the bombs on it) would fix it.

User avatar
Holger
Site Admin
Posts: 2977
Joined: Fri Jun 18, 2004 4:13 pm
Location: Germany
Contact:

Re: where did Element Properties go?

Post by Holger » Wed Mar 25, 2015 7:11 pm

> I finally noticed: this problem occurs with some levelsets and not with others. I think it might be levels using the EMC engine
> vs. RnD engine.

Ah, now I understand the problem you described, and why it happened: No, it's not related to the game engine, but to the graphics set used by a given level set (one of the EMC sets in this case). If it uses the classic definitions for redefining "door" area artwork, the old graphics are used that do not contain the new graphic objects yet (like properties button graphics or zoom button graphics). So either I have to update the EMC "door" graphics set to also contain those new graphics, or I have to move those new graphics to a separate image file, where they are not kept unchanged in artwork sets that globally redefine the "door" graphics. I think I will go with the latter.

Regarding the outdated copyright year, just do a "git pull" to get the latest (updated for 2015) version of the screen background graphics (it's there for some time now, so I wonder why you apparently don't have it yet).

Regarding wraparound: No, neither the R'n'D nor the EMC game engine have this feature (but only the Supaplex engine).

Regarding the unsolvable level: I think I will fix it at least in the DX BD set...

User avatar
Holger
Site Admin
Posts: 2977
Joined: Fri Jun 18, 2004 4:13 pm
Location: Germany
Contact:

Re: where did Element Properties go?

Post by Holger » Wed Mar 25, 2015 8:36 pm

> I think I will go with the latter.

Done now (see after "git pull"). As the newly added editor graphics for new/changed buttons are now moved to a new image file, they will still be used even if "RocksDoor" was redefined as a whole. Therefore, the new graphics will now be displayed even with existing level sets with redefined graphics -- just check that EMC level set again. (BTW: I haven't changed the "CONF" button (which was labelled "INFO" before), as this is only a cosmetical change, but not a functional change of buttons (like the new "zoom" button which was "properties" before).)

Post Reply