And is this server side or client side? If its server side, you have to completely rework the fundamental way the client/server relationship works to make that feasbile. If its client-side, you can still mod around it easily.
And for what? The edge case of a chest being buried being invisible to a x-ray mod? why should a buried chest be special? If you have to put forth the effort to hide a chest completely buried, why not put forth the effort to hide anything the player cannot rightly see? You are convoluting the code to deal with an edge case.
Exactly this!
xray textures and cheat mods are not the 'norm'. Better that Mojangs development resources are spent on real bugs, enhancing existing content and mechanics and introducing new goodies so that the game continues to be fun.
If some jerk wants to mess with your stuff on a server, the ease with which the client can be modded will let that jerk find your stuff. It's really up to the admins of the server to define and enforce the rules of the server.
And is this server side or client side? If its server side, you have to completely rework the fundamental way the client/server relationship works to make that feasbile. If its client-side, you can still mod around it easily.
And for what? The edge case of a chest being buried being invisible to a x-ray mod? why should a buried chest be special? If you have to put forth the effort to hide a chest completely buried, why not put forth the effort to hide anything the player cannot rightly see? You are convoluting the code to deal with an edge case.
It would be server side. Would not use raytracing. Anything that is a block, but not a full block (chests, redstone, stairs, ect.) would not be visible to anyone, not sent by the server unless the visibility of the "visibility structure" (or whatever I want to call it) turns true.
To be more clear, this method would basically set all instances of aforementioned blocks to the same visibility, and checks if any part of the structure is near other blocks that players can see through and/or can be occupied by a player. No matter how large the structure is, it is invisible. The moment there is a relevant chunk update, say you mine a block that a button was on (eposing a 1x1 tunnel filled with redstone wire), the whole structure turns visible. Not moddable (in SMP anyway) and would make SMP function a little better as less data would be sent. I had redstone on my mind when I thought of this, not chests. never thought I would say that....
EDIT: And by occupy I mean could you make a 1x2 tunnel filled with it, could you walk through it? also requires it to be stacked unto itself
Rollback Post to RevisionRollBack
"I'm an outsider by choice, but not truly.
It’s the unpleasantness of the system that keeps me out.
I’d rather be in, in a good system. That’s where my discontent comes from:
being forced to choose to stay outside.
My advice: Just keep movin’ straight ahead.
Every now and then you find yourself in a different place."
-George Carlin
It would be server side. Would not use raytracing. Anything that is a block, but not a full block (chests, redstone, stairs, ect.) would not be visible to anyone, not sent by the server unless the visibility of the "visibility structure" (or whatever I want to call it) turns true.
To be more clear, this method would basically set all instances of aforementioned blocks to the same visibility, and checks if any part of the structure is near other blocks that players can see through and/or can be occupied by a player. No matter how large the structure is, it is invisible. The moment there is a relevant chunk update, say you mine a block that a button was on (eposing a 1x1 tunnel filled with redstone wire), the whole structure turns visible. Not moddable (in SMP anyway) and would make SMP function a little better as less data would be sent. I had redstone on my mind when I thought of this, not chests. never thought I would say that....
EDIT: And by occupy I mean could you make a 1x2 tunnel filled with it, could you walk through it? also requires it to be stacked unto itself
That's quite the overhaul you're proposing. It's essentially object culling on the server side. It would reduce bandwidth use, but at the cost of server processing. I'm thinking this would introduce quite the lag on larger servers with all the player movement in various areas of the map.
I'm thinking quite a lot of resources would be needed for this overhaul and it would only really satisfy people that are concerned about 'cheaters'.
Eventually someone would work around this with a cheating mod that automated reconnaissance.
I'm thinking this would introduce quite the lag on larger servers with all the player movement in various areas of the map.
Eventually someone would work around this with a cheating mod that automated reconnaissance.
as I said it would not use raytracing, so no it wouldn't use player vector data to determine if it was visible or not. It would just be block placement based and run through the code without any regard to players. If it isn't visible, don't send the data, if it is, send it, apply culling client side. Cheaters would actually have to hack/mod the server to get around it.
Rollback Post to RevisionRollBack
"I'm an outsider by choice, but not truly.
It’s the unpleasantness of the system that keeps me out.
I’d rather be in, in a good system. That’s where my discontent comes from:
being forced to choose to stay outside.
My advice: Just keep movin’ straight ahead.
Every now and then you find yourself in a different place."
-George Carlin
*decided to reply to a post that has already been replied to*
It has nothing to do with that. The texture packs had every single block, exept diamond and chests, be invisible. There isn't much you can do to stop it.
As for that bukkit mod, it works fine. All it does it change the appearance. Glitches with it can be solved by rejoining.
Wrong again. Go download a see through pack. Place a diamond block inside a wall with no gaps and I promise the pack won't show it.
Defeats the purpose of raiding someone in a PVP server then.
You know, not everyone likes their stuff being stolen, and you could always just use dispensers to hold "prize raid goods" on your little PvP server. Seriously, I think that my idea would resolve a lot more problems than all these anti-x-ray texture pack ideas.
as I said it would not use raytracing, so no it wouldn't use player vector data to determine if it was visible or not. It would just be block placement based and run through the code without any regard to players. If it isn't visible, don't send the data, if it is, send it, apply culling client side. Cheaters would actually have to hack/mod the server to get around it.
Except its not as straight foraward as you think.
First, you have to add the overhead of keeping track of all of these collections of visible blocks. Since all of the air, many caves, and the entire surface will be visible, they will be one giant visibility group. You have to figure out how to handle the groups extending across multiple chunks, and not only merge the groups, but divide them. Every time you place a block, it could potentially be cutting off a large swath of visibility, which has to be detected and modified. And since before you bury an item, it is visible, it will be sent to the client of everyone nearby, and a modified client could easily remember it from when it was visible, and even go so far as to highlight things that have been hidden that were visible. So a buried chest would be undetectable... as long as you never unbury it, and no-one was around when you put it there in the first place.
You know, not everyone likes their stuff being stolen, and you could always just use dispensers to hold "prize raid goods" on your little PvP server. Seriously, I think that my idea would resolve a lot more problems than all these anti-x-ray texture pack ideas.
I mentioned the exact same idea, twice now! I can't think why this solution doesn't work, it's a little more inconvient, but it still gets the job done.
First, you have to add the overhead of keeping track of all of these collections of visible blocks. Since all of the air, many caves, and the entire surface will be visible, they will be one giant visibility group.
My method would only add the not-solid object's faces and faces connecting to them to visibility groups, so under my implementation, naturally generated caves would not be effected.
You have to figure out how to handle the groups extending across multiple chunks, and not only merge the groups, but divide them. Every time you place a block, it could potentially be cutting off a large swath of visibility, which has to be detected and modified.
Yeah, I know, It's one of those fun things that would go on during chunk updates. I'm not Notch or Jeb_, the most I've done in java is make a combo-box calculator. And it also isn't my job to figure this out. I've thought of enough of the idea it could be developed and all the kinks worked out during development. If it were added it could really decrease amount of data sent/received (possibly immensely), while increasing server processing. Most servers are on nice computers anyways :smile.gif: plus not everyone has not the best internet
And since before you bury an item, it is visible, it will be sent to the client of everyone nearby, and a modified client could easily remember it from when it was visible, and even go so far as to highlight things that have been hidden that were visible. So a buried chest would be undetectable... as long as you never unbury it, and no-one was around when you put it there in the first place.
Well, this is true. But most likely they would either have to be at the right place at the right time, or log every chest ever placed on the server. if someone actually went so far as to do this, people could just spam chests in random locations and then pick them back up, as such a mod would most likely just spit out vector data to a .txt file. And with over 100 vector entries to read, remember, and reach each location to find nothing would be a pain :tongue.gif:
Rollback Post to RevisionRollBack
"I'm an outsider by choice, but not truly.
It’s the unpleasantness of the system that keeps me out.
I’d rather be in, in a good system. That’s where my discontent comes from:
being forced to choose to stay outside.
My advice: Just keep movin’ straight ahead.
Every now and then you find yourself in a different place."
-George Carlin
My method would only add the not-solid object's faces and faces connecting to them to visibility groups, so under my implementation, naturally generated caves would not be effected.
so.... if there is ANY air block involved, it is visible? Or am I misunderstanding how you decide to send the visibility group to the client?
Yeah, I know, It's one of those fun things that would go on during chunk updates. I'm not Notch or Jeb_, the most I've done in java is make a combo-box calculator. And it also isn't my job to figure this out. I've thought of enough of the idea it could be developed and all the kinks worked out during development. If it were added it could really decrease amount of data sent/received (possibly immensely), while increasing server processing. Most servers are on nice computers anyways :smile.gif: plus not everyone has not the best internet
You can't assert that a method is more efficient if you can't explain it beyond a basic level. That would be like saying "just take the lowest value element, put it at the bottom of the list, and repeat for each element. You will end up with a sorted list in linear time". While that may be an accurate description of certain sorting algorithms, those are the ones that give you n2 time, and perform worse than more complex methods.
Well, this is true. But most likely they would either have to be at the right place at the right time, or log every chest ever placed on the server. if someone actually went so far as to do this, people could just spam chests in random locations and then pick them back up, as such a mod would most likely just spit out vector data to a .txt file. And with over 100 vector entries to read, remember, and reach each location to find nothing would be a pain :tongue.gif:
You can also remember when a chest is picked up, since it should be easy to detect the difference between removing a chest and blocking it off. If you want to do decoy chests, you can do them now. Place 100 chests, and only use 2 or 3. Every empty one would be a pain. And being in the right area wouldn't be that hard.
I'm not saying this couldn't work, but at the current level of conception its impossible to say whether it is really worthwhile, or if it is going to do more harm than good.
so.... if there is ANY air block involved, it is visible? Or am I misunderstanding how you decide to send the visibility group to the client?
Yes, that or a glass block, web block, glass pane, door, or any occupy-able space(ladder block, trapdoor, sugarcane, rails, 1 glass pane, redstone torches any above another non-solid block ect.). This would make sure if it is suppposed to be visible, it is, and also makes sure invisible tunnels are not created.
You can't assert that a method is more efficient if you can't explain it beyond a basic level.
I did explain it on a basic level. I formed an entire idea, just not the technical ideas, I really don't know much about chunks and how they work, and certainly not enough to say EXACTLY how to implement my idea. Besides, Notch has fun figuring stuff like that out.
You can also remember when a chest is picked up, since it should be easy to detect the difference between removing a chest and blocking it off.
Is there a definable difference sent to the client between "harvested" and "hidden", besides maybe an item sprite showing up?
boom fire problem solved, no item sprite logged
unless there is something else?
Rollback Post to RevisionRollBack
"I'm an outsider by choice, but not truly.
It’s the unpleasantness of the system that keeps me out.
I’d rather be in, in a good system. That’s where my discontent comes from:
being forced to choose to stay outside.
My advice: Just keep movin’ straight ahead.
Every now and then you find yourself in a different place."
-George Carlin
If you can suggest an adequate solution, I'd be all for mojang implementing it.
Agreed. In any case, if you were to make texture packs to be without transparency enabled, you would end up with retarded torches, and ease of modding against.
Yes, that or a glass block, web block, glass pane, door, or any occupy-able space(ladder block, trapdoor, sugarcane, rails, 1 glass pane, redstone torches any above another non-solid block ect.). This would make sure if it is suppposed to be visible, it is, and also makes sure invisible tunnels are not created.
And people will never have anything they need to hide with a visible block near it, nope. Esp. if you are trying to hide redstone. Really, the amount of things this will actually hide is miniscule.
I did explain it on a basic level. I formed an entire idea, just not the technical ideas, I really don't know much about chunks and how they work, and certainly not enough to say EXACTLY how to implement my idea. Besides, Notch has fun figuring stuff like that out.
I said beyond a basic level. At the basic level, it sounds fine. When I try to look at it in more precise detail and work out edge cases, the complexity skyrockets.
Is there a definable difference sent to the client between "harvested" and "hidden", besides maybe an item sprite showing up?
boom fire problem solved, no item sprite logged
in one case, the chest simply disappears. In another, something else is placed which blocks its visibility. Even if the latter case comes with the former, the latter part is still detectable. Esp. since code to test exactly that case must exist in the server, so it would be trivial for the modder to copy it to a client and re-utilize it for that check.
And people will never have anything they need to hide with a visible block near it, nope. Esp. if you are trying to hide redstone. Really, the amount of things this will actually hide is miniscule.
that looks very weirdly worded to me... anyways you would be able to hide redstone circuitry, especially basic traps. and you would be able to hide chests
I said beyond a basic level. At the basic level, it sounds fine. When I try to look at it in more precise detail and work out edge cases, the complexity skyrockets.
well I did describe it beyond but I did not make a mod that implements my idea, sorry. I have thought about it, and how to fix the issue in a proper manner, and I think this could work. Implementation is really the only thing I didn't talk about. Yes, it seems complex when you talk about it, but when it's being coded it isn't that complex. Then you read the code later like "how did I manage to make that work perfectly, yet not understand it now? wow, must've phased out there."
in one case, the chest simply disappears. In another, something else is placed which blocks its visibility. Even if the latter case comes with the former, the latter part is still detectable. Esp. since code to test exactly that case must exist in the server, so it would be trivial for the modder to copy it to a client and re-utilize it for that check.
Is this info sent to the client though, or would it require more snooping the server?
Rollback Post to RevisionRollBack
"I'm an outsider by choice, but not truly.
It’s the unpleasantness of the system that keeps me out.
I’d rather be in, in a good system. That’s where my discontent comes from:
being forced to choose to stay outside.
My advice: Just keep movin’ straight ahead.
Every now and then you find yourself in a different place."
-George Carlin
that looks very weirdly worded to me... anyways you would be able to hide redstone circuitry, especially basic traps. and you would be able to hide chests
Aren't air blocks used in certain redstone circuits?
well I did describe it beyond but I did not make a mod that implements my idea, sorry. I have thought about it, and how to fix the issue in a proper manner, and I think this could work. Implementation is really the only thing I didn't talk about. Yes, it seems complex when you talk about it, but when it's being coded it isn't that complex. Then you read the code later like "how did I manage to make that work perfectly, yet not understand it now? wow, must've phased out there."
Alright, give me an overview. What data structures are you using to store the groups? How are you keeping track of its visibility? How are you detecting it is split? how are you merging them?
And keep in mind, this has to handle the case of a large, complex redstone circuit being revealed, altered, so vast swathes of it can become hidden, merged, split, possibly frequently. Esp. if someone sets up something with pistons to automate the placement and removal of blocks to do this.
Is this info sent to the client though, or would it require more snooping the server?
it has to be. If you place a block next to it, you have to tell the client that block was placed. Even if you tell it that all of the now-hidden blocks were removed, the client still knows they were there. You tell it that a block was placed next to the visibility group, and the client will have everything it needs to detect that it is now hidden, and subsequently ignore the command that those blocks were removed, and furthermore highlight that this was hidden, so burring a chest can make the greifer's client light up and put a beacon on it. if you EVER access your hidden chest while someone is near enough to receive the visibility update, it will be completely revealed.
easy solution - store valuables in a dispenser instead of a chest (this has been suggested already)
Mojang/mod solution - add a server option that forces the map to use the old full-block chests instead of the smaller animated ones. Basically revert smp chests back to 1.7 ...the option to atleast.
I don't use x-ray textures so I'm not certain if these are true fixes. Either way, that's my two cents...spend em how ya like.
Alright, give me an overview. What data structures are you using to store the groups? How are you keeping track of its visibility? How are you detecting it is split? how are you merging them?
And keep in mind, this has to handle the case of a large, complex redstone circuit being revealed, altered, so vast swathes of it can become hidden, merged, split, possibly frequently. Esp. if someone sets up something with pistons to automate the placement and removal of blocks to do this.
Possibly something with arrays? Or anything that could store the vector data/instance names to say "hey, these take the visibility of this Boolean, oh and tell me if there is a chunk update near any of them, and where, so I can check stuff out". Each group could be treated almost like a "blob" of geometry, where each "blob" is a visibility group. visibility would just be an object attribute. To reveal, split, or merge them, just add or remove any block data you would need to during a chunk update, essentially re-configuring or changing visibility or children of all effected "blobs". That's the best I can explain it technically right now. I need to write an essay :/
it has to be. If you place a block next to it, you have to tell the client that block was placed. Even if you tell it that all of the now-hidden blocks were removed, the client still knows they were there. You tell it that a block was placed next to the visibility group, and the client will have everything it needs to detect that it is now hidden, and subsequently ignore the command that those blocks were removed, and furthermore highlight that this was hidden, so burring a chest can make the greifer's client light up and put a beacon on it. if you EVER access your hidden chest while someone is near enough to receive the visibility update, it will be completely revealed.
I really don't know about any of this. someone would be going awfully far to find these chests, couldn't they just make servers probe for code that would allow people to do sneaky stuff like this?
Rollback Post to RevisionRollBack
"I'm an outsider by choice, but not truly.
It’s the unpleasantness of the system that keeps me out.
I’d rather be in, in a good system. That’s where my discontent comes from:
being forced to choose to stay outside.
My advice: Just keep movin’ straight ahead.
Every now and then you find yourself in a different place."
-George Carlin
Possibly something with arrays? Or anything that could store the vector data/instance names to say "hey, these take the visibility of this Boolean, oh and tell me if there is a chunk update near any of them, and where, so I can check stuff out". Each group could be treated almost like a "blob" of geometry, where each "blob" is a visibility group. visibility would just be an object attribute. To reveal, split, or merge them, just add or remove any block data you would need to during a chunk update, essentially re-configuring or changing visibility or children of all effected "blobs". That's the best I can explain it technically right now. I need to write an essay :/
and this is precisely the "beyond the basics" level where it gets confusing. If you simply have an array-type data structure, how do you know which group any given block belongs to? If you can't easily know that, you can't know if modifying any given block is going to impact the visibility groups, or if a block is in a hidden visibility group so it is not sent to the server. You have to detect that a given block change has resulted in a single visibility group being split in two, with the possibility that the group is split locally and connects somewhere else. For instance, if you have a loop that is hidden, and place a block in it, then it breaks the group locally, but they are still connected in one group.
I really don't know about any of this. someone would be going awfully far to find these chests, couldn't they just make servers probe for code that would allow people to do sneaky stuff like this?
Most of the code will be there already because this was implemented. Adding this in would be doing the work for them. You make a client mod, and we are right back were we started; cheaters cheating. And how do you propose to have servers probe for code? All you need is a mod that has a vanilla copy that it offers for any probing that would be happening.
edit: to be clear, I'm not concerened with simply doing it. I am concerened with doing it efficiently.
Exactly this!
xray textures and cheat mods are not the 'norm'. Better that Mojangs development resources are spent on real bugs, enhancing existing content and mechanics and introducing new goodies so that the game continues to be fun.
If some jerk wants to mess with your stuff on a server, the ease with which the client can be modded will let that jerk find your stuff. It's really up to the admins of the server to define and enforce the rules of the server.
It would be server side. Would not use raytracing. Anything that is a block, but not a full block (chests, redstone, stairs, ect.) would not be visible to anyone, not sent by the server unless the visibility of the "visibility structure" (or whatever I want to call it) turns true.
To be more clear, this method would basically set all instances of aforementioned blocks to the same visibility, and checks if any part of the structure is near other blocks that players can see through and/or can be occupied by a player. No matter how large the structure is, it is invisible. The moment there is a relevant chunk update, say you mine a block that a button was on (eposing a 1x1 tunnel filled with redstone wire), the whole structure turns visible. Not moddable (in SMP anyway) and would make SMP function a little better as less data would be sent. I had redstone on my mind when I thought of this, not chests. never thought I would say that....
EDIT: And by occupy I mean could you make a 1x2 tunnel filled with it, could you walk through it? also requires it to be stacked unto itself
"I'm an outsider by choice, but not truly.
It’s the unpleasantness of the system that keeps me out.
I’d rather be in, in a good system. That’s where my discontent comes from:
being forced to choose to stay outside.
My advice: Just keep movin’ straight ahead.
Every now and then you find yourself in a different place."
-George Carlin
That's quite the overhaul you're proposing. It's essentially object culling on the server side. It would reduce bandwidth use, but at the cost of server processing. I'm thinking this would introduce quite the lag on larger servers with all the player movement in various areas of the map.
I'm thinking quite a lot of resources would be needed for this overhaul and it would only really satisfy people that are concerned about 'cheaters'.
Eventually someone would work around this with a cheating mod that automated reconnaissance.
as I said it would not use raytracing, so no it wouldn't use player vector data to determine if it was visible or not. It would just be block placement based and run through the code without any regard to players. If it isn't visible, don't send the data, if it is, send it, apply culling client side. Cheaters would actually have to hack/mod the server to get around it.
"I'm an outsider by choice, but not truly.
It’s the unpleasantness of the system that keeps me out.
I’d rather be in, in a good system. That’s where my discontent comes from:
being forced to choose to stay outside.
My advice: Just keep movin’ straight ahead.
Every now and then you find yourself in a different place."
-George Carlin
Wrong again. Go download a see through pack. Place a diamond block inside a wall with no gaps and I promise the pack won't show it.
You know, not everyone likes their stuff being stolen, and you could always just use dispensers to hold "prize raid goods" on your little PvP server. Seriously, I think that my idea would resolve a lot more problems than all these anti-x-ray texture pack ideas.
Except its not as straight foraward as you think.
First, you have to add the overhead of keeping track of all of these collections of visible blocks. Since all of the air, many caves, and the entire surface will be visible, they will be one giant visibility group. You have to figure out how to handle the groups extending across multiple chunks, and not only merge the groups, but divide them. Every time you place a block, it could potentially be cutting off a large swath of visibility, which has to be detected and modified. And since before you bury an item, it is visible, it will be sent to the client of everyone nearby, and a modified client could easily remember it from when it was visible, and even go so far as to highlight things that have been hidden that were visible. So a buried chest would be undetectable... as long as you never unbury it, and no-one was around when you put it there in the first place.
I mentioned the exact same idea, twice now! I can't think why this solution doesn't work, it's a little more inconvient, but it still gets the job done.
And how would you know they did it? ;D
And dispensers/furnaces/crafting tables also appear on most xray packs.
My method would only add the not-solid object's faces and faces connecting to them to visibility groups, so under my implementation, naturally generated caves would not be effected.
Yeah, I know, It's one of those fun things that would go on during chunk updates. I'm not Notch or Jeb_, the most I've done in java is make a combo-box calculator. And it also isn't my job to figure this out. I've thought of enough of the idea it could be developed and all the kinks worked out during development. If it were added it could really decrease amount of data sent/received (possibly immensely), while increasing server processing. Most servers are on nice computers anyways :smile.gif: plus not everyone has not the best internet
Well, this is true. But most likely they would either have to be at the right place at the right time, or log every chest ever placed on the server. if someone actually went so far as to do this, people could just spam chests in random locations and then pick them back up, as such a mod would most likely just spit out vector data to a .txt file. And with over 100 vector entries to read, remember, and reach each location to find nothing would be a pain :tongue.gif:
"I'm an outsider by choice, but not truly.
It’s the unpleasantness of the system that keeps me out.
I’d rather be in, in a good system. That’s where my discontent comes from:
being forced to choose to stay outside.
My advice: Just keep movin’ straight ahead.
Every now and then you find yourself in a different place."
-George Carlin
so.... if there is ANY air block involved, it is visible? Or am I misunderstanding how you decide to send the visibility group to the client?
You can't assert that a method is more efficient if you can't explain it beyond a basic level. That would be like saying "just take the lowest value element, put it at the bottom of the list, and repeat for each element. You will end up with a sorted list in linear time". While that may be an accurate description of certain sorting algorithms, those are the ones that give you n2 time, and perform worse than more complex methods.
You can also remember when a chest is picked up, since it should be easy to detect the difference between removing a chest and blocking it off. If you want to do decoy chests, you can do them now. Place 100 chests, and only use 2 or 3. Every empty one would be a pain. And being in the right area wouldn't be that hard.
I'm not saying this couldn't work, but at the current level of conception its impossible to say whether it is really worthwhile, or if it is going to do more harm than good.
Yes, that or a glass block, web block, glass pane, door, or any occupy-able space(ladder block, trapdoor, sugarcane, rails, 1 glass pane, redstone torches any above another non-solid block ect.). This would make sure if it is suppposed to be visible, it is, and also makes sure invisible tunnels are not created.
I did explain it on a basic level. I formed an entire idea, just not the technical ideas, I really don't know much about chunks and how they work, and certainly not enough to say EXACTLY how to implement my idea. Besides, Notch has fun figuring stuff like that out.
Is there a definable difference sent to the client between "harvested" and "hidden", besides maybe an item sprite showing up?
boom fire problem solved, no item sprite logged
unless there is something else?
"I'm an outsider by choice, but not truly.
It’s the unpleasantness of the system that keeps me out.
I’d rather be in, in a good system. That’s where my discontent comes from:
being forced to choose to stay outside.
My advice: Just keep movin’ straight ahead.
Every now and then you find yourself in a different place."
-George Carlin
Agreed. In any case, if you were to make texture packs to be without transparency enabled, you would end up with retarded torches, and ease of modding against.
And people will never have anything they need to hide with a visible block near it, nope. Esp. if you are trying to hide redstone. Really, the amount of things this will actually hide is miniscule.
I said beyond a basic level. At the basic level, it sounds fine. When I try to look at it in more precise detail and work out edge cases, the complexity skyrockets.
in one case, the chest simply disappears. In another, something else is placed which blocks its visibility. Even if the latter case comes with the former, the latter part is still detectable. Esp. since code to test exactly that case must exist in the server, so it would be trivial for the modder to copy it to a client and re-utilize it for that check.
that looks very weirdly worded to me... anyways you would be able to hide redstone circuitry, especially basic traps. and you would be able to hide chests
well I did describe it beyond but I did not make a mod that implements my idea, sorry. I have thought about it, and how to fix the issue in a proper manner, and I think this could work. Implementation is really the only thing I didn't talk about. Yes, it seems complex when you talk about it, but when it's being coded it isn't that complex. Then you read the code later like "how did I manage to make that work perfectly, yet not understand it now? wow, must've phased out there."
Is this info sent to the client though, or would it require more snooping the server?
"I'm an outsider by choice, but not truly.
It’s the unpleasantness of the system that keeps me out.
I’d rather be in, in a good system. That’s where my discontent comes from:
being forced to choose to stay outside.
My advice: Just keep movin’ straight ahead.
Every now and then you find yourself in a different place."
-George Carlin
Aren't air blocks used in certain redstone circuits?
Alright, give me an overview. What data structures are you using to store the groups? How are you keeping track of its visibility? How are you detecting it is split? how are you merging them?
And keep in mind, this has to handle the case of a large, complex redstone circuit being revealed, altered, so vast swathes of it can become hidden, merged, split, possibly frequently. Esp. if someone sets up something with pistons to automate the placement and removal of blocks to do this.
it has to be. If you place a block next to it, you have to tell the client that block was placed. Even if you tell it that all of the now-hidden blocks were removed, the client still knows they were there. You tell it that a block was placed next to the visibility group, and the client will have everything it needs to detect that it is now hidden, and subsequently ignore the command that those blocks were removed, and furthermore highlight that this was hidden, so burring a chest can make the greifer's client light up and put a beacon on it. if you EVER access your hidden chest while someone is near enough to receive the visibility update, it will be completely revealed.
Mojang/mod solution - add a server option that forces the map to use the old full-block chests instead of the smaller animated ones. Basically revert smp chests back to 1.7 ...the option to atleast.
I don't use x-ray textures so I'm not certain if these are true fixes. Either way, that's my two cents...spend em how ya like.
possibly, but there probably would be a way to work around it.
Possibly something with arrays? Or anything that could store the vector data/instance names to say "hey, these take the visibility of this Boolean, oh and tell me if there is a chunk update near any of them, and where, so I can check stuff out". Each group could be treated almost like a "blob" of geometry, where each "blob" is a visibility group. visibility would just be an object attribute. To reveal, split, or merge them, just add or remove any block data you would need to during a chunk update, essentially re-configuring or changing visibility or children of all effected "blobs". That's the best I can explain it technically right now. I need to write an essay :/
I really don't know about any of this. someone would be going awfully far to find these chests, couldn't they just make servers probe for code that would allow people to do sneaky stuff like this?
"I'm an outsider by choice, but not truly.
It’s the unpleasantness of the system that keeps me out.
I’d rather be in, in a good system. That’s where my discontent comes from:
being forced to choose to stay outside.
My advice: Just keep movin’ straight ahead.
Every now and then you find yourself in a different place."
-George Carlin
and this is precisely the "beyond the basics" level where it gets confusing. If you simply have an array-type data structure, how do you know which group any given block belongs to? If you can't easily know that, you can't know if modifying any given block is going to impact the visibility groups, or if a block is in a hidden visibility group so it is not sent to the server. You have to detect that a given block change has resulted in a single visibility group being split in two, with the possibility that the group is split locally and connects somewhere else. For instance, if you have a loop that is hidden, and place a block in it, then it breaks the group locally, but they are still connected in one group.
Most of the code will be there already because this was implemented. Adding this in would be doing the work for them. You make a client mod, and we are right back were we started; cheaters cheating. And how do you propose to have servers probe for code? All you need is a mod that has a vanilla copy that it offers for any probing that would be happening.
edit: to be clear, I'm not concerened with simply doing it. I am concerened with doing it efficiently.