Descriptive Problem Summary: I have turfs that utilize a null icon, and have mouse_opacity set to 2 for the use of Click() which normally works fine, but the latest update seems to break this. I can't get it to work at all when running from the source that's compiled in 1196, and it's kind of back and forth in the hosted one that utilizes an older BYOND version.
Numbered Steps to Reproduce Problem: 1: Create a regular turf of any kind, and cover the map. 2: Create another turf, make it a higher layer, set its icon to null, set its mouse_opacity to 2, give it a Click() proc, and place it over part of the map. 3: Compile, run, click, get nothing. 4: Give it an icon, and watch it start working.
Code Snippet (if applicable) to Reproduce Problem:
Expected Results: To be able to click turfs that have no icon.
Actual Results: Click does not appear to be called on turfs that have no icon, even when utilizing mouse_opacity = 2
Does the problem occur:
Every time? Or how often? Every time when running from the source, and likely when hosting with 1196. Back and forth in older hosting.
In other games? Most likely.
In other user accounts? Not tested.
On other computers? Not tested.
When does the problem NOT occur? When the turf has an icon.
Did the problem NOT occur in any earlier versions? If so, what was the last version that worked? I just went back to 1195 and I've had no problem with it.
Workarounds: Nothing that I know of. Maybe an icon with a single pixel in it, but I doubt it.
ID:1305482
 Jun 28 2013, 12:33 am
|
|||||||||||||
Resolved
| |||||||||||||
|
Jun 28 2013, 5:03 am
|
|
Lummox JR
   |
Lummox JR resolved issue with message:
|
I noticed this fix wasn't listed in the fixes page for 1197; so I just wanted to stop by and say that it IS fixed, and thanks for getting to it so quickly.
| |
Hm? I'm still having wonky issues with this and two turfs on the same loc.
As I understand it, two turfs ontop of each other in the .dmm file will cause the upper most one to be added to the overlays of the other turf, but for all intensive purposes it still works the same way. The uppermost turf in my game is an invisible tile used for triggering certain events when you pass this tile. I've set its mouse_opacity to 0, however when I mouse over the turf, it doesn't show the bottom most turf in the status bar, and as such doesn't let me Click() it, which is the real problem. This happens regardless of whether or not the bottommost turf is mouse_opacity = 2. | |
Regardless, the functionality of mouse_opacity just isn't working.
Having said that, I doubt a fix will be possible looking at the way DM handles turfs, but I thought I'd bring it up anyway. | |
Because the turf you're trying to click doesn't exists, the icon was added as a underlay to the top-most turf you had in the map editor. Should work fine if you test the turf independent of the top-most turf.
| |
Rushnut, the behavior you're seeing is actually correct.
When you stack turfs in the editor, the only turf that actually exists is the topmost one; the others all become underlays. Underlays, like overlays, are Appearances--none of them is an actual turf. Giving your topmost turf mouse_opacity=0 will not, therefore, redirect clicks to one of its underlays, because the underlay is visual only; it is not a turf and can't receive a click. | |
Correct, when you explain it like that, sure. But when you look at it in the intended result, kind of way, is there no work around plausible?
It's not a massive issue since I just shifted the effect turfs to be a child of the clickable turfs, but I can see areas where it would still be an issue in other projects. | |
Have them be transparent objs rather than turfs. Having more than one turf on a square is byond the scope of byond.
| |
It sounds to me as if you're trying to use stacked turfs as a form of poor man's multiple inheritance. Trying to achieve multiple inheritance by doing an end run around the language never really works well. I'd have to know more about what you were trying to do specifically to advise you (which would be more of a Developer Help type issue), but I can think of several better ways of handling event triggers and click triggers together without tying each one to a specific turf type. If you're only using this special turf type to turn on event triggering, why not a var instead?
| |
I think you're misunderstanding, and yes I do know that I could use an obj or mob, or anything really, but ultimately I feel as though at the bottom line having two turfs "ontop" of each other, should still provide the mouse_opacity functionality, but the way you've explained how it works makes it seem rather difficult to accomplish on the backend so, whatever I guess.
To clarify, I was using a turf as a trigger, when Entered(atom/A) the A would have its walkTrigger() called. Specific events happen at specific points in the map. Ultimately I could of just refrenced their positions hard-code, but that's not particularly modular (And an especial problem if I want to incorporate multiple maps). In order to work around the missing mouse_opacity problem, I simply made the triggers a child of the turf/ground type, thus giving it the same Click() functionality, whilst still retaining its own functionality. | |
As Lummox has stated, you can still rather easily trigger events simply by providing a variable to the turf that you can then change inside the map editor to trigger the event.
| |
Rushnut wrote:
To clarify, I was using a turf as a trigger, when Entered(atom/A) the A would have its walkTrigger() called. Specific events happen at specific points in the map. Ultimately I could of just refrenced their positions hard-code, but that's not particularly modular (And an especial problem if I want to incorporate multiple maps). Right, you definitely want to have the turf handle its own triggering. The real question is why you'd need to implement triggers in a type unto themselves. In order to work around the missing mouse_opacity problem, I simply made the triggers a child of the turf/ground type, thus giving it the same Click() functionality, whilst still retaining its own functionality. Why wouldn't you just want the original turf--the one you click--to have a var that says whether it has triggers or not? The Entered() proc for this type, or one of its parent types, could check that var and determine if further action is needed. Or likewise if the clickability is an unusual feature for this turf, that could be handled with a var as well. Essentially this tile should be no different from similar tiles around it, the same type, and you could have vars control its behaviors that make it act differently. For instance, if a turf has a special enter event, you could just set var/entervent to a type path. event It's all a matter of design. | |
Again, to reiterate, I know there's a thousand design choices or methods I could take to work around my problem, but fundamentally my problem resolves down to: two turfs on one tile is wonky.
Having a basic understanding of how turfs work, I understand why it has to be that way, but fundamentally from a game maker point of view, if I have the ability to place two turfs ontop of each other in the map editor, then I instinctively think that they should both work and function, as you'd expect. The fact that they don't is clearly explained, and I understand that, but if possible the real design choice to make would be to fix the wonky behaviour in the first place, otherwise you should explicately state cases in which functionality won't work for X reasons. Or the other alternative I guess is to not allow multiple turfs on a single tile under any circumstances, which is a complete step in the wrong direction. | |
I don't see it as wonky behavior; the fact of it is you only ever have one turf, and it may simply have cardboard cutout imitation turfs behind it. If you replace the turf, it becomes a "cutout" itself so the new turf can work. The only thing that could really be done here is somehow making that clearer in the map editor.
| |
From the game developers point of view, when he places two turfs down on one spot, they function perfectly as you'd expect.
There are exceptions to this, I get that it is intended behaviour for the functionality of turfs to work as a whole, but if you're trying to hackily push extra features into a system that isn't really completely set up to handle those features, you should at least be mentioning it somewhere. | |
I think you are missing the engine limitation that a single turf may only exist in each tile location. It isn't actually possible to have two turfs in the same tile... It may appear as if there are two turfs there, but its just one turf with an underlay.
If byond had the ability to have two turfs in one location, it would break EVERYTHING. Having a single turf per tile location is very much so on purpose. It allows over 4 million turfs total at run time, and provides order in proc ordering (Exit Exited Enter Entered) as well as stability and reliability. The real "wonky" thing here is that you won't use a simple design solution to solve your problem with the limitation. | |
No you're missing my point entirely.
I get that the engine doesn't properly support multiple turfs on one tile, but it attempts to trick the user into believing it has via the underlay trick, hence to the developer it looks more or less like he has been successful in his endeavors. Then suddenly he tries using mouse_opacity (And probably a few other things too) and it doesn't work and he's sitting there wondering why. If not to fix the missing functionality in the first place, then a ref entry on the subject should be provided. | |
Rushnut wrote:
No you're missing my point entirely. Sure, that falls under a lack of documentation, although I'm pretty sure this is documented somewhere, I just don't know where. | |