The letter of the week is B, for Benedryl. Progress has been a little slower this week, but ongoing, because you can't write code when you can't see straight.
As is probably apparent by now, more bug fix work was done this week, although one of the fixes didn't pan out like I had hoped and will need a proper final fix in the next build (511.1385). I expect that will come soon, but not quite today. I do however have an approach that I think will shut that bug down once and for all. Fortunately it's very obscure.
Work on 512 continues. I've begun putting together the underlying structures I'll need for visual contents, an idea from Ter13 that I think has massive potential. So far my plan is that only movables can be in an atom's visual contents, and only movables and/or turfs can have them. (That plan may be subject to change. For instance I may decide I actually want turfs to be allowed in visual contents, or that maybe /image would be a viable visual container--although /image would be more complex to handle.) This will entail two new vars, vis_contents and vis_locs. An atom can be part of multiple atoms' visual contents, and can even appear indirectly more than once in the same grandparent atom. The only strict rule here is that circular references of course won't be allowed, just like with regular contents.
The way visual contents will work is that when an atom is converted into icons its appearance is handled, followed by the images, followed by the visual contents; and then all those are sorted. There is however a catch, which is that with visual contents, the objects in that list will retain their own atom IDs for mouse interaction--which means changing up some code on the client end. (I may also want to provide a mechanism whereby these objects can still act like live overlays, and therefore not retain their IDs or individual mouse_opacity.)
The goal of all this is, as stated in the post, so you can have either easy-to-change overlays, setup complex HUD containers, and more. I think a lot of really exciting stuff can come out of this, especially for game interfaces.
If you haven't hit up the donation box or become a Member yet, now's a great time to do so--especially for Membership, because next weekend is a long weekend here in the USA, and what better way to duck your relatives at the inevitable picnic than to play games? (Actually I'm looking forward more to seeing relatives, but that's what happens when you get old.) Let's get summer started right!
ID:2248510
 May 19 2017, 11:15 am
|
|
Turfs in another turfs visual_contents would be awesome. It would make multiple z-levels easy to implement. An "empty space" turf could be setup to add the turf from the z-level "below" to its visual_contents, thus allowing you to see the turf a level below. Can this please be a thing?
| |
Loganbacca wrote:
Turfs in another turfs visual_contents would be awesome. It would make multiple z-levels easy to implement. An "empty space" turf could be setup to add the turf from the z-level "below" to its visual_contents, thus allowing you to see the turf a level below. Can this please be a thing? Reading this gave me the idea making seamless maps might be feasible in 512. Something to think about later. | |
FKI wrote:
Loganbacca wrote: If you read the suggestion thread, I mentioned ulterior motives for this new system. This suggestion was a bridge to bigger ideas and resolving a ton of existing feature requests. | |
I've basically wanted it for seamless maps and never really considered it for map leveling (is it layering in this case? I dunno...), that would be pretty damned epic.
| |
I'm keeping an open mind about turfs in turfs. If the initial work goes okay then I don't see a reason it wouldn't be addable.
| |
What is going to be on the next update
| |
I had only skimmed it before reading Loganbacca's post. (I tend to do that when my brain is fried; in others words, my attention was elsewhere, completely missing the bigger picture.)
| |
Loganbacca wrote:
Turfs in another turfs visual_contents would be awesome. It would make multiple z-levels easy to implement. An "empty space" turf could be setup to add the turf from the z-level "below" to its visual_contents, thus allowing you to see the turf a level below. Can this please be a thing? Okay, I have a question based on this idea. I haven't decided yet to make turfs available in visual contents, but if I do, I'm going to need some clarifications. Here's the problem I'm running into. The building of the icons for a given object looks like this: - Get current appearance, possibly with separate pixel info (movables separate pixel info except when animating), and glides - Call either GetCappearanceItileList() or GetFlickItileList(), depending on presence of flick - Call GetImageChainItileList() to add images - Build icons recursively for any objects in visual contents - Account for float layers (not done in recursive steps) Later on, all these icons will be sorted. But if you have a turf inside another turf's visual_contents, a very important question arises: How is that layered? In theory, I suppose you could have all your turfs on FLOAT_PLANE--which resolves to 0 by default. Then on a turf Q with another turf R below it, you'd put an obj (O) in Q's visual contents with a lower plane, and then R in O; but that's kind of a pain. Alternatively if you know what turfs this will be done with, you can use a higher plane or layer for the higher turfs, or a lower plane/layer for the lower levels--but you'd also have to apply any such changes to all those turfs' contents. Basically what I'm saying is, this would be doable if turfs were allowed in turf.vis_contents, but it wouldn't be easy and I'd like to find some way to make it easy. Do you have any ideas on that? | |
I say just sort the layering how it would be sorted if all the stuff on those turfs were on a single turf, let the developer worry about special edge cases. As for the appearance of the turf itself, that's the tricky part, as most turfs are gonna have the same layer and there's no real instances where two can exist together right now and using the 'newest one takes over' method of placing a new turf down wouldn't play so nice.
Might only be possible to have one turf inside of turf.vis_contents with some way to tell it which one takes precedence visually. I can't imagine a good way to have a bunch of turfs within a single turf without it becoming a god damn mess. | |
The use case I'm thinking of would have the child turf rendered above the parent turfs sprite, but below any other objects in the parent turfs contents (or visual_contents for that matter). I would also have no intention of putting multiple turfs in visual_contents. So basically sort it above the parent turf, but below any other objects. If there is more than one turf in visual_contents then just render them in the order they were added.
Allowing turfs in any objects visual_contents could be an alternative as you suggested. You could then make a dummy object with no other sprites except for a turf in visual_contents. The dummy object could then be put in another turfs contents, and the dummy object would control which layer and plane it is rendered on. It seems a little convoluted, but would allow for a lot of flexibility. I'd also like to hear Ter13's thoughts on this as he clearly has a "bigger picture" in mind. | |
As someone also doing MultiZ, I'd say it should render BELOW the parent turf.
If you want the bottom turf to show through entirely, ie: a hole, have the parent turf have no sprite. If you did as you say, and had it render above, you couldn't have things like "glass bottom" floors, or floors that had grilles in them, you'd have to use an object (an overlay would render as part of the parent turf, and thus, appear below still) | |
CrimsonVision wrote:
As someone also doing MultiZ, I'd say it should render BELOW the parent turf. That is actually a very good point. | |
It should layer according to plane and layer.
If you want to do multi-z, you should set up your map's layers/planes accordingly by modifying the layers at runtime according to z layer. This way there is no hard limitation either way. The root object should be considered the bottom of the stack provided that layers and planes are equal. I can picture players wanting to use turfs to map out the interiors of vehicles that can move around the map such as boats or space shuttles in SS13. As such, the ability to render turfs on top of other turfs should be preserved at all costs. | |
layers/planes are acceptable.
My point was more: "if it had to be above or below, it should be below", not that it should absolutely be below and nothing else. | |
Ter13 wrote:
It should layer according to plane and layer. So basically, no special consideration for making, say, a balcony overlook or bridge easy, but instead requiring users to figure it out themselves? I think I'm pretty okay with that, even though I'd prefer something easier. Of course verb availability also could be an issue if people are expecting to be able to use verbs on items made visible in this way (mouse stuff is obviously an exception), but I really, really don't want to drill down into vis_contents on every view() call, let alone open the possibility of including vis_locs as well which would complicate everything. (Also, I do not consider adding vis_contents or vis_locs to "set src" to be reasonable.) | |
That was my synopsis in the original thread, that it's probably right out to implement it with verbs.
| |
I also sympathize with you on the allergy thing -- I couldn't breathe most of the week and my eyes kept watering up like crazy. I don't get off for federal holidays though, so I'm not really looking forward to Monday at all. Sunday is my birthday though. :p