Adminblocks
- Sanjar Khan
- Trustee
- Offline
- Posts: 1766
- Joined: May 24th, 2011, 1:40 pm
- Location: Leiden, Zuid Holland
Adminblocks
Had this idea for awhile, shot it into staff yesterday, sprouted quite a discussion wether it was possible. But the general concensus was that it would be awesome and very useful; Admincrete (solid) counterparts to every building block. It would open up many possibilities. /solid would enter solid mode rather than just replace stone.
Ferrisbuler2: i will stay but i might not post cus of ollieboy
- Sanjar Khan
- Trustee
- Offline
- Posts: 1766
- Joined: May 24th, 2011, 1:40 pm
- Location: Leiden, Zuid Holland
Re: Adminblocks
I want adminglass, I want adminpink, I want admingrass, I want admindirt.
Ferrisbuler2: i will stay but i might not post cus of ollieboy
Re: Adminblocks
Yeah, and maybe a cuboid like command to convert normal blocks to admin blocks. We can call it /zadd.
The first law of thermodynamics states that you don't discuss thermodynamics.
- Sanjar Khan
- Trustee
- Offline
- Posts: 1766
- Joined: May 24th, 2011, 1:40 pm
- Location: Leiden, Zuid Holland
Re: Adminblocks
Try zoning a sphere without the air around it, or a canyon that runs all across main without making it impossible for guests to build on
Ferrisbuler2: i will stay but i might not post cus of ollieboy
Re: Adminblocks
you mean you want to design an admin-kind of block for all blocks?
<KingCrab> oh btw, did you Kirshi is my babie's daddy?
Re: Adminblocks
It's called block hardening and is available for some other servers. It's basically "zoning stuff as you place blocks" instead of arbitrarily shaped areas.
This would most likely require per-block metadata and won't be viable until there is a DB (i.e. when there's block tracking as well =).
This would most likely require per-block metadata and won't be viable until there is a DB (i.e. when there's block tracking as well =).
War does not determine who is right - only who is left. - Bertrand Russell
Re: Adminblocks
I'm sorry. I'm being an asshole today.
I see your point Sanjar. This would be useful.
Didn't the other server software with custom blocks just use more IDs? That would probably use the least memory, and the extra processing power you'd have to use to convert the ID before sending would be negligible, even on a large server.
However, I have a feeling that this wouldn't fit too well with fcraft's current structure, but that's me guessing.
I see your point Sanjar. This would be useful.
Didn't the other server software with custom blocks just use more IDs? That would probably use the least memory, and the extra processing power you'd have to use to convert the ID before sending would be negligible, even on a large server.
However, I have a feeling that this wouldn't fit too well with fcraft's current structure, but that's me guessing.
The first law of thermodynamics states that you don't discuss thermodynamics.
Re: Adminblocks
Warning: This post contains technobabble.
The main problem with custom block types is having to translate between custom block codes (for internal representation) and standard block codes (for actually sending to the client). That means every time someone joins a 512x512x64 map, like our main, this conversion has to be done about 17 million times. This also means that I have to either compress the map in small chunks (slow), make a copy of the whole map every time someone joins a world (slightly faster, but makes huge memory spikes), or always keep two copies of each map in memory (fastest, wastes memory ALL the time).
I am paranoid about degrading performance, so I've been trying to stay away from custom blocks until I find an efficient solution to the aforementioned problems.
The main problem with custom block types is having to translate between custom block codes (for internal representation) and standard block codes (for actually sending to the client). That means every time someone joins a 512x512x64 map, like our main, this conversion has to be done about 17 million times. This also means that I have to either compress the map in small chunks (slow), make a copy of the whole map every time someone joins a world (slightly faster, but makes huge memory spikes), or always keep two copies of each map in memory (fastest, wastes memory ALL the time).
I am paranoid about degrading performance, so I've been trying to stay away from custom blocks until I find an efficient solution to the aforementioned problems.
Re: Adminblocks
Would it be possible to instead add something like a /zonenot command, in order to exclude certain blocks from the zone (like air)?
<CMB> KingCrab72: Some mixture and contrast would be nice tbh Ollie
<Ollieboy> Some mixture and contrast of your face on my penis would also be nice
<Ollieboy> Some mixture and contrast of your face on my penis would also be nice
Re: Adminblocks
<KingCrab> oh btw, did you Kirshi is my babie's daddy?
Re: Adminblocks
The Genius comes forward...Astelyn wrote:Would it be possible to instead add something like a /zonenot command, in order to exclude certain blocks from the zone (like air)?
also, perhaps add parameters to "/zone" (like /zonenot)
similair to /paste pink
if you decide to do this, usage could be:
capi: /zone pink
now adding pink blocks ONLY to the next zone.
you can now /zadd
capi: /zadd pinkcupoftea supop
that way, it would be optional so you can still just regular /zadd
I'm not sure if this is a limitation though and whether commands can store that kind of information for other commands :|
I would assume youre brilliant enough to do this...
>l>