Thread Rating:
  • 2 Vote(s) - 5 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Construction Boogaloo
#16
Still though, what's the difference between the admin swap tile tool (which i've seen done PLENTY of times in action) and something in-game, which can be restricted by being resource intensive?
Reply
#17
(12-10-2017, 05:23 AM)Sundance Wrote: Still though, what's the difference between the admin swap tile tool (which i've seen done PLENTY of times in action) and something in-game, which can be restricted by being resource intensive?

Depends on how the latter is implemented. If it's done as overlays, every individual customized tile has its own overlay. This is bad. When admins swap tiles, they're making them all the same /turf object or changing their sprite to the same thing (i.e. all pointing at the same thing). That is better than each turf saying "hi, I look exactly like that tile over there but I'm special and need my own sprite, here it is".

This is why my suggestion involved some interface to select from existing sprites; we then simply change the icon_state var of the relevant turf to the right one.
Reply
#18
(12-10-2017, 06:21 PM)Mordent Wrote:
(12-10-2017, 05:23 AM)Sundance Wrote: Still though, what's the difference between the admin swap tile tool (which i've seen done PLENTY of times in action) and something in-game, which can be restricted by being resource intensive?

Depends on how the latter is implemented. If it's done as overlays, every individual customized tile has its own overlay. This is bad. When admins swap tiles, they're making them all the same /turf object or changing their sprite to the same thing (i.e. all pointing at the same thing). That is better than each turf saying "hi, I look exactly like that tile over there but I'm special and need my own sprite, here it is".

This is why my suggestion involved some interface to select from existing sprites; we then simply change the icon_state var of the relevant turf to the right one.

how difficult would it be to have the floor tile object save the icon_state of the turf it was on, and when it's placed down onto a turf(2), that turf(2) changes icon_state to the one that was passed by the tile? 
that should be less ressource intensive than overlays right ?
Reply
#19
(12-10-2017, 06:21 PM)Mordent Wrote:
(12-10-2017, 05:23 AM)Sundance Wrote: Still though, what's the difference between the admin swap tile tool (which i've seen done PLENTY of times in action) and something in-game, which can be restricted by being resource intensive?

Depends on how the latter is implemented. If it's done as overlays, every individual customized tile has its own overlay. This is bad. When admins swap tiles, they're making them all the same /turf object or changing their sprite to the same thing (i.e. all pointing at the same thing). That is better than each turf saying "hi, I look exactly like that tile over there but I'm special and need my own sprite, here it is".

This is why my suggestion involved some interface to select from existing sprites; we then simply change the icon_state var of the relevant turf to the right one.

I would be cool with that completely. It'd just be a matter of making an ok-looking GUI. Realistically if all the turfs are the same size, you could lay them out in a scrollable grid and just set the window's default size to match them, avoiding complex menu greeble.
Reply
#20
(12-11-2017, 12:11 PM)John Warcrimes Wrote: ...

Sure. Now how do you deal with stacks of them? Yes, we could make a stack contain a list of floor tiles, and work like a literal stack as in the programming structure (last one in, first one out), but that'd come with its own load of fun and work.

What I'm getting at is that I think we all agree the idea of "make it so that you can create your swanky pad via floor tiles" is a good thing. Each variant comes with its own pros and cons, and there's no objectively better way of doing it so it mostly boils down to whatever the coder who implements it wants to do.

Which really makes these sorts of implementation questions somewhat moot, but hey, transparency!
Reply
#21
I confess I'm not familiar enough with your branch to know how stacks are handled and whether or not they actually hold the objects passed to them.

I'm kinda just tossing the pasta at the wall, I apologise.
Reply
#22
(12-11-2017, 12:37 PM)John Warcrimes Wrote: I confess I'm not familiar enough with your branch to know how stacks are handled and whether or not they actually hold the objects passed to them.

I'm kinda just tossing the pasta at the wall, I apologise.

I doubt much has changed on that front, to be honest. Typically when these turn into implementation discussions, stuff becomes a bit unproductive fairly quickly. If we assume you're limited to the existing icon_states (so existing turf things), coming up with the interface for how you select which you want would be a worthwhile topic!
Reply
#23
Also this seems like an okay place to suggest bringing back Construction rounds on occasion, probably to LLJK1 ?
Reply
#24
I was never a fan of construction rounds, but I've always thought it would be neat if there was an intentionally unfinished room on the station that people could repair and build in to suit whatever project they had in mind for the round.

A place where baisc lighting and atmospheric/heating were already set up
Reply
#25
(12-12-2017, 08:15 AM)Frank_Stein Wrote: I was never a fan of construction rounds, but I've always thought it would be neat if there was an intentionally unfinished room on the station that people could repair and build in to suit whatever project they had in mind for the round.

A place where baisc lighting and atmospheric/heating were already set up

I'm probably biased toward wanting to try because I never even knew it was a thing while LLJK3 was up. 

Totally agree on having some sort of large, barren multipurpose hangar at general or maintenance access, less like the cogmap "construction area" and more like a completely empty engine room.

e: Caveat, I worry such a room would just become a place for mechanics to build station-griefing emporiums, rather than an actual build-it-in-your-image space. By design, the station should already come equipped with whatever workspaces the crew is gonna need, so a spare room is either gonna be superfluous or malicious. This as opposed to actually building up a needed department from the ground up, to suit the current need.
Reply
#26
Naw, there's already rooms like that on station maps, but yes these are construction areas rather than empty spaces. And mechanics will build deadly traps, construction area or none. Hell I don't have a problem with that, I'd go so for as to advocate it. Better than building it in unconstructable rooms such as the outpost.

On the topic of Construction... yeah it wasn't a very good mode, the flaws of it were clear as day.

Firstly was the atmos. Built a room? Good luck getting ANY AIR in it.
Secondly was decorations. No matter how many HOURS you put into the station, nothing really looked as good as a prebuilt station, due to the lack of decorative items (trees, posters, etc).
So you were left with soulless, cold, empty rooms. That's all I remember of #3. That and the occasional braindead.

Unfortunetely construction of new rooms hasn't really developed much since then, it's still impossible to repressure rooms, it's still impossible to create a pretty room / repair a room fully in a reasonable amount of time.
Reply
#27
I like to use the little gaps around corners on cog1/cog2 or bits in the hallways as custom rooms.

i would do it way more if they didn't invariably cause suffocation
Reply


Forum Jump:


Users browsing this thread: 2 Guest(s)