Player Built Houses in Developer Help

Page: 1 2
ID:150030
 
Dec 31 2001, 7:56 pm (Edited on Jan 10 2002, 3:04 pm)
How would I make it so you can build houses in only a specific area. For example you go to the land deeeds office and buy a plot of land. Then you get a piece of paper that allows you to construct anything on your property. Now how would I make it so you can have a lot of these plots. Maybe have each plot warp you to another layer but what if you want to have a garden. This is serious to build chemicals. However I have space issuses here. Now how would I conect it so you can build stairs to an upstairs(or downstairs) land plot. Finally how would I make it so if you build a door the door key is automatically added to your inventory and it is a UNIQUE Key from everyone elses.(However it can be copied.
Is this even remotely possible without moths of programming.

[idea]
when you enter the Player plot city zone it warps you to the city zone's layer.

[Update]
I've included code.
#1 Dec 31 2001, 7:59 pm
It's possible without months of programming, but it isn't possible without having months of programming experience.
#2 Dec 31 2001, 8:10 pm
Now, I may not know everything how byond works, but I'm pretty sure I know how to do this.

How would I make it so you can build houses in only a specific area. For example you go to the land deeeds office and buy a plot of land. Then you get a piece of paper that allows you to construct anything on your property.

well, first off you dont even need paper, have a var. example?
mob/var/area1owned = 0
mob/var/area2owned = 0
you will need allot of these for each buyable area. lets say you buy area1, you change your var:
mob/var/area1owned = 0
to this:
mob/var/area1owned = 0
which can be accomplished by adding:
usr.area1owned == 1
once you buy it.

now to build, have a area such as this:
area/area1
when you choose, lets say a verb that says build, check to see what area you are on, if it is area1 then check to see if your var, area1owned, is area1owned==1. if so, have it continue, else have it say something like:
usr << "I am sorry, but either this land is not buildable or you dont have a right to build here.

Now how would I make it so you can have a lot of these plots. Maybe have each plot warp you to another layer but what if you want to have a garden. This is serious to build chemicals. However I have space issuses here. Now how would I conect it so you can build stairs to an upstairs(or downstairs) land plot.

sorry, lost me there

Finally how would I make it so if you build a door the door key is automatically added to your inventory and it is a UNIQUE Key from everyone elses.(However it can be copied.

ok, the method I provided probably wont make this workable with keys, instead you could use a verb. such as AddOwner(), which will give them area1owned==1, so they could enter your door. now your door, would first check the area, then if it is area1, it check if usr.area1owned==1, if so, open the door, if not, do nothing.

I hope this works

DDR, Boom Boom Dollar standard master:Geo
#3 Jan 1 2002, 3:19 am
In response to Geo (#2)
Geo wrote:
well, first off you dont even need paper, have a var. example?
mob/var/area1owned = 0
mob/var/area2owned = 0
you will need allot of these for each buyable area. lets say you buy area1, you change your var:
mob/var/area1owned = 0
to this:
mob/var/area1owned = 0
which can be accomplished by adding:
usr.area1owned == 1
once you buy it.

Sorry, but this is about the worst way to do anything, and I have to step in and say something (even at this hour) lest this practice creep into future programs.

What you should do is have a var for the area that points to the mob's key (and character name, since the mob might have more than one character), then have a var for the mob that points back to the area. Having a zillion different area vars and checking each one to see whether it's 0 or 1 is absolutely pointless.

Lummox JR
#4 Jan 1 2002, 3:38 am
Exadv1 wrote:
How would I make it so you can build houses in only a specific area. For example you go to the land deeeds office and buy a plot of land. Then you get a piece of paper that allows you to construct anything on your property.

What you'd probably want to do would be to set up various areas with vars saying which player owns them. (Or, you could do this with the turfs in an area.) Objects to represent land deeds would be easy enough to add, and each mob could have a list of all the properties they own. A central system for buying and selling land shouldn't be too terrible to work out.

Now how would I make it so you can have a lot of these plots. Maybe have each plot warp you to another layer but what if you want to have a garden. This is serious to build chemicals. However I have space issuses here.

Space issues are a big problem, since map sizes (and numbers thereof) are not dynamic. Owning a lot of plots is really just as easy as owning one; just make sure that whatever you design to point out ownership, it recognizes that users can own more than one property, so you should use a list var to represent their holdings.

Now how would I conect it so you can build stairs to an upstairs(or downstairs) land plot.

This is fairly easy. Assuming you have several Z layers staked out for this purpose, all you need to do is add the ability to build stairs or another story onto a building during construction/design. (How you handle construction is up to you.) Each staircase would be a simple teleporter leading to another Z layer. Perhaps, for example, a directive to add stairs leading up (not available for the top layer) would cause a new floor to be added to the house automatically.

Finally how would I make it so if you build a door the door key is automatically added to your inventory and it is a UNIQUE Key from everyone elses.(However it can be copied.

This is a good idea, and not too hard to program. The door can be given the mob's ckey, plus character name, like this:
obj/door
  var/keyname

  proc/SetOwner(mob/M)
    if(M.client) M.keyname="[M.client.ckey]:[M.name]"
    // no idea why client would be null, but just in case...
    else M.keyname=":[M.name]"

  proc/CreateKey(atom/newloc)
    new /obj/key(newloc,src,keyname)

  verb/Open()
    var/mob/M=usr
    for(var/obj/key/key in M)
      if(key.purpose==src && key.keyname==keyname)
        openme()
        return
    usr << "You don't have a key for this door."

obj/key
  var/keyname
  var/authusername
  var/purpose

  New(atom/newloc,_purpose,_keyname)
    ..()
    if(_purpose)
      name="key to [_purpose]"
      purpose=_purpose
    keyname=_keyname

It's possible to take this even further and allow each key to only be used by its original owner or by an authorized user. I'll leave that code to you.

Lummox JR
#5 Jan 1 2002, 4:04 am
In response to Lummox JR (#4)
Lummox JR wrote:
Space issues are a big problem, since map sizes (and numbers thereof) are not dynamic.

Not sure what you are thinking of here, but map sizes are completely dynamic.

I once created a system to load and unload maps into new z levels, and change map size, on the fly.
#6 Jan 1 2002, 6:24 am (Edited on Jan 1 2002, 6:55 am)
In response to Deadron (#5)
Thanks for the assistence Lummox JR. Happy New Year.
Now here's how buying goes. You pick a number of the plot you wish to purchase. Then it checks all the deeds in the world to see if anyone has bought the land. Now when you wish the build it checks your deeds variable to see if you actually own the land. That way you can trade and give away deeds. Every area has a number. Now how would I make it so if you pick 1 it is area, 2 area2, 3 area3 ...
[EDIT]
Couldm you add a few comments you sorta lost me at some parts.
#7 Jan 1 2002, 11:23 am
In response to Deadron (#5)
Deadron wrote:
Lummox JR wrote:
Space issues are a big problem, since map sizes (and numbers thereof) are not dynamic.

Not sure what you are thinking of here, but map sizes are completely dynamic.

I once created a system to load and unload maps into new z levels, and change map size, on the fly.

Gads, now that's intriguing.
What I was referring to actually was BYOND's lack of dynamic map support, that the number of maps involved doesn't seem changeable on the fly. If you've found a clever workaround for this, though, I'd love to hear about it.

Lummox JR
#8 Jan 1 2002, 7:52 pm
In response to Lummox JR (#3)
Sorry, but this is about the worst way to do anything, and I have to step in and say something (even at this hour) lest this practice creep into future programs.

I have to say, no it is not. There is probably also no way to prove that I am wrong about this. There are MANY differant ways to accomplish something, but usually 1-3 ways someone prefers. For example, there is a Greater Liche gaurding the gate to the crypts of Nycrombi, since it probably wouldnt negotiate at all, I'd toss a little explosive (not todays grenades, the type you'd make at home with very little money) grenade over to it and let that do the talking, while many others would prefer using a gun/sword/magic. This is the way I prefer to make this type of code, while you do not. I also prefer having allot of variables, because I feel it adds more customazation depending which var does what.
#9 Jan 1 2002, 8:07 pm
In response to Geo (#8)
*nod* The var-heavy way -would- work. I dont think theres any question of that. However, how -fast- would it work ^_~ how efficiently?

One of my programming teachers gave us an example of one system he used to work on. It was a outstanding accounts program, designed to generate reports on overdue payments.

In the form that he was originally working on, it would take 3 days out of every week to work, and take up the -entire- network to do it. After recoding it, and intellegently recoding the decicisions, he got it down to 10 hours, working in the -background- of the network.

Just because something works, doesnt mean it works efficiently ^^;

But the var way gives you a place to start. Maybe instead of doing it exactly like that, you could optimize it a bit more as you go *shrug* Programming is strange that way ^_^

Elorien
#10 Jan 1 2002, 8:13 pm
In response to Elorien (#9)
Elorien wrote:
*nod* The var-heavy way -would- work. I dont think theres any question of that. However, how -fast- would it work ^_~ how efficiently?

It mainly depends on what the vars would go to. I dont use vars for everything, but I tend to add a good amount. Also, it would actually work without slowing down at all (then again, my computer is pretty fast).

In the form that he was originally working on, it would take 3 days out of every week to work, and take up the -entire- network to do it. After recoding it, and intellegently recoding the decicisions, he got it down to 10 hours, working in the -background- of the network.

That is pretty impressive. makes me wonder.....

Just because something works, doesnt mean it works efficiently ^^;

That is true, but it also doesn't mean that if it is already working at a good speed with no slowdown, why try to make it better?

Final Fantasy Tactic novice, DDR adept: Geo
#11 Jan 1 2002, 8:34 pm
In response to Geo (#8)
Geo, listen to Lummox for a minute.

When you start having on the order of five thousand different areas and variables to deal with, you'll see...
#12 Jan 1 2002, 8:45 pm
In response to Spuzzum (#1)
heres an idea to make it harder. Make it so that every thing they put down(bed, wall, rug) cost money. That way they couldent have a mantion with on plot. and make stairs realy costly. You know that would be like adding anouther house so you dont want the to have a 7 floor house or anything.
#13 Jan 1 2002, 11:20 pm
In response to Geo (#8)
Geo wrote:
Sorry, but this is about the worst way to do anything, and I have to step in and say something (even at this hour) lest this practice creep into future programs.

I have to say, no it is not.

Actually it is.

But that's okay, if you gotta learn for yourself you gotta learn for yourself. I can respect that, but it's likely to be a painful lesson.
#14 Jan 2 2002, 9:12 am
In response to Geo (#8)
Geo wrote:
Sorry, but this is about the worst way to do anything, and I have to step in and say something (even at this hour) lest this practice creep into future programs.

I have to say, no it is not. There is probably also no way to prove that I am wrong about this.

Actually the burden of proof is on you to find a worse way, but since I said "about" I leave myself a little leeway to still be right on that. This is indeed about the worst way, if not the worst way ever, you could go about programming this.

The fact that different techniques are available doesn't make yours good, or even fractionally adequate in this case. For any situation with more than 2 or 3 plots of land available, the amount of variable juggling would rapidly get so insane that it would make the code a mess; it would in every case be slightly slower than a simple reference, and it would make the code more complicated, harder to understand, harder to alter, and just generally more difficult. Worse, you'd be hard-coding the sucker, making it inextensible. To actually put this var system into use on a scale even remotely like what Exadv wanted would be impossible. Yes, I think it's safe to use the word "impossible" there. Hit just one bug and this programming methodology would fall apart faster than an ice sculpture in a smelter.

I can't disparage this method enough. It's bad programming practice for anything but a few special scenarios, and you should always look to generalize whenever you can. When generality is the key, using specific numerical vars to say whether there's a connection to specific objects is not going to cut it. Consider shopkeeper code for example. You could have a var for every possible item every shopkeeper could possibly sell, and make it non-zero if they actually have the item. But the code even to fill in the item menu would be nightmarish, and maintaining all those variables and the gigantic switch statements to deal with them would be asinine. The specific-var method is so terrible next to other ways of doing it that it's not even worth counting as viable. The same goes here.

This isn't to put you down or anything, but just to say that you're defending a way of programming that isn't really defensible. It's like saying "I can drive just fine with my legs." Maybe you can, but that doesn't make it a good idea. Like driving with your legs, the var-each method only has a few rare cases where it's worth using at all.

There are MANY differant ways to accomplish something, but usually 1-3 ways someone prefers.

Yes, but the way you suggested would actually not work for the task at hand, except on an extremely small test-case scale that wouldn't really do any good to anybody, since what Exadv wanted was a general system. It isn't really much good even as an example, because it wouldn't teach the basic principles needed to set up a larger system. The only reason you might use it would be as a substitute for something better while working out other details of land ownership, like house construction.

And there are in fact many ways to accomplish this task; the var-each method just happens not to be one of them. Details about land plots could be stored in a central repository, or each plot could simply have information about who owns it and a list of available plots could be built up as needed. Each mob could contain a list of what plots they own, or that info could be generated from the plots themselves. I prefer a little redundancy myself. However, a few things are abundantly clear: Some kind of mob/key reference is crucial; some kind of area reference (or plot number) for the mob is helpful, and a list thereof even more helpful; lists in general would make this whole thing a lot simpler.

For example, there is a Greater Liche gaurding the gate to the crypts of Nycrombi, since it probably wouldnt negotiate at all, I'd toss a little explosive (not todays grenades, the type you'd make at home with very little money) grenade over to it and let that do the talking, while many others would prefer using a gun/sword/magic. This is the way I prefer to make this type of code, while you do not.

This isn't a matter of preference, though; not everything is. The analogy isn't even good, unless the Liche happens to utterly destroy any player who doesn't use a range-striking weapon that kills on its first hit. But then if that's the case, you're on the wrong side of the analogy because what you're trying to defend is the person who stubbornly tries to use their sword when clearly it's not going to get them anywhere. Those who choose the way that doesn't work, knowing there are real solutions, are only choosing to fail.

Again, not a matter of preference. If you say, "I prefer to make my cake watery," then you're not making cake, just eggy hot chocolate. Your method simply isn't workable, for this situation or thousands of others. Preference would come into play in how you use references and lists, how you choose to name your variables, whether you store info in one place or another. Hard-coding a large-scale task when soft-coding is not only "preferable", but literally infinitely easier to do, just isn't a position you can defend as valid. Hard-coding is good for special circumstances only. In this case you'd be developing a piece of code that was massively unwieldy, extremely slow, all but impossible to adapt to another RPG in the future, and prone to extremely intractable bugs.

I also prefer having allot of variables, because I feel it adds more customazation depending which var does what.

I'm not sure what you mean here, but it seems to me that issues of customization could be handled an incredible number of ways, which speaks more to the preference issue you spoke of. I don't see how having a different var for each plot of land would improve customization any; if land were customized, it could be done in the map editor as easily as anywhere else, perhaps with special vars in the areas within the map editor to indicate other things.

Like, say, each plot of land could have a chance of yielding a trace amount of gold ore. This would be well suited to a variable for the area, which could be edited on the map. If there were several different things that could be mined, this would be a place where your many-var approach might work out. If however you could mine any number of things or have other attributes out the wazoo, then it becomes time to consider alternatives.

Lummox JR
#15 Jan 2 2002, 12:11 pm
In response to Lummox JR (#14)
Actually the burden of proof is on you to find a worse way, but since I said "about" I leave myself a little leeway to still be right on that. This is indeed about the worst way, if not the worst way ever, you could go about programming this.

Again, you can not prove that the way you code things works in a hassle-free way for me, as I can not prove my ways will be easy to understannd with you. I do not say your coding was to hard to understand and hopeless for all to try it. I will leave this at that.

For any situation with more than 2 or 3 plots of land available, the amount of variable juggling would rapidly get so insane that it would make the code a mess

You may not have much skill, er better change that so it doesn't sound like I'm trying to start a argument but I can't find a better word for it, with handling allot of variables, I however do. You may, however know allot when it comes to coding a key which may take more time than my way, but may be easier.

Hit just one bug and this programming methodology would fall apart faster than an ice sculpture in a smelter.

Not just this, but just about everything unless you remove the error. one error WILL cause one game's function not to be able to work, such as pointing a turf/grass's icon_state to make it gras instead of grass would leave the grass's icon looking like nothing.

I can't disparage this method enough. It's bad programming practice for anything but a few special scenarios, and you should always look to generalize whenever you can.

This may be your opinion, but I could say it's bad programming for anyone but a few specail scenerios to try to generalize. While allot (yes I do mean allot) of other programmers may disagree and go with your opinion, this is just mine.

Yes, but the way you suggested would actually not work for the task at hand, except on an extremely small test-case scale that wouldn't really do any good to anybody, since what Exadv wanted was a general system. It isn't really much good even as an example, because it wouldn't teach the basic principles needed to set up a larger system. The only reason you might use it would be as a substitute for something better while working out other details of land ownership, like house construction.

so, would you like me to program the whole thing and send it to you gift wrapped in thing golden sheets with a red silk ribbon just to prove that I am write and it is workable?

This isn't a matter of preference, though; not everything is. The analogy isn't even good, unless the Liche happens to utterly destroy any player who doesn't use a range-striking weapon that kills on its first hit. But then if that's the case, you're on the wrong side of the analogy because what you're trying to defend is the person who stubbornly tries to use their sword when clearly it's not going to get them anywhere. Those who choose the way that doesn't work, knowing there are real solutions, are only choosing to fail.

.... obviously you arn't getting it. the melee weapon would work, however I try to stay behind and toss as much grenades as possible before it could cast any spell.

Again, not a matter of preference. If you say, "I prefer to make my cake watery,"

I do not! (just joking, c'mon I HAD to say that.)

then you're not making cake, just eggy hot chocolate.

yes you are, just "watery cake" (another boring joke, but it's true, it's just how you look at things)

I won't respond to any more posts after this, unless I find it insulting. I feel you are trying to insultme and prove me wrong quite often, so I will try to end it no by saying "Done". So I am done discussing this topic.

Final Fantasy Tactic novice, DDR adept: Geo
#16 Jan 2 2002, 12:23 pm
In response to Geo (#15)
Geo wrote:
I won't respond to any more posts after this, unless I find it insulting. I feel you are trying to insultme and prove me wrong quite often, so I will try to end it no by saying "Done". So I am done discussing this topic.

That's not what he's trying to do, but at this point I'll remind Lummox of my upcoming BYONDscape article which encourages one to "stop arguing when the other person isn't going to change their mind" and "it's okay for other people to be wrong".

The important information has been communicated here for anyone interested/open to absorbing it, and it's time to move on...
#17 Jan 2 2002, 1:18 pm (Edited on Jan 2 2002, 1:24 pm)
In response to Geo (#15)
Geo wrote:
Actually the burden of proof is on you to find a worse way, but since I said "about" I leave myself a little leeway to still be right on that. This is indeed about the worst way, if not the worst way ever, you could go about programming this.

Again, you can not prove that the way you code things works in a hassle-free way for me, as I can not prove my ways will be easy to understannd with you. I do not say your coding was to hard to understand and hopeless for all to try it. I will leave this at that.

I'm not saying you'd necessarily have an easy time with it (actually, my concern was more with how Exadv would do this, since it's his project), nor did I claim it'd be hassle-free. But your method absolutely guarantees hassles, and big ones at that, with no advantages whatsoever. The only thing it has going for it is that the disadvantages are minimal in a hypothetical test case that nobody's even talking about.

For any situation with more than 2 or 3 plots of land available, the amount of variable juggling would rapidly get so insane that it would make the code a mess

You may not have much skill, er better change that so it doesn't sound like I'm trying to start a argument but I can't find a better word for it, with handling allot of variables, I however do. You may, however know allot when it comes to coding a key which may take more time than my way, but may be easier.

Handling a lot of variables isn't a matter of skill so much as doing lots of copying and pasting, and setting up code to run through the list of such variables when a simple object reference would not only be better, but would indeed be the only thing that made sense. And you may well be experienced with writing such code, but it's useless experience because it will never make you a better programmer; all you're doing is reinforcing a horrifically bad habit.

Hit just one bug and this programming methodology would fall apart faster than an ice sculpture in a smelter.

Not just this, but just about everything unless you remove the error. one error WILL cause one game's function not to be able to work, such as pointing a turf/grass's icon_state to make it gras instead of grass would leave the grass's icon looking like nothing.

Here's the problem: With the amount of repeated code necessary to handle a multi-var approach, one bug could easily be multiplied about 500 times. It could also show up in obscure places that would be hard to spot. Soft-coding centralizes bugs.

I can't disparage this method enough. It's bad programming practice for anything but a few special scenarios, and you should always look to generalize whenever you can.

This may be your opinion, but I could say it's bad programming for anyone but a few specail scenerios to try to generalize. While allot (yes I do mean allot) of other programmers may disagree and go with your opinion, this is just mine.

This really isn't a matter for opinion; not here. A preference for specifics vs. generalization could be, but for the type of algorithm Exadv clearly wants, and for most such algorithms, there is a clear choice. Generalization makes the code run much faster and it's much more readable, fixable, adaptable, and so on. The kind of ultra-specificity in hard-coding things has absolutely no value in the vast majority of programming situations, and it's foolish to try to defend it for those cases. There are situations where you could make a strong case for it, but this isn't even close to being one of them.

Where your argument on opinion would have merit would be in discussing precisely how to go about implementing various details of the system, but the overall structure should clearly not be a multi-var approach. It's untenable here.

so, would you like me to program the whole thing and send it to you gift wrapped in thing golden sheets with a red silk ribbon just to prove that I am write and it is workable?

But you can't prove that. The fact that you could get such code to work wouldn't make it the right code for the job. You see, if you were to use hard-coding to set up a map in which, say, 100 plots of land could be bought, what do you think would happen when someone wanted to change it to 200? What if they wanted 121? The code would have to be drastically reworked to fit this, because you'd have hard-coded everything.

Hard-coding is not adaptable, not extensible, and not the least bit logical. Furthermore, taken to this extreme instead of small test cases, it's incredibly slow.

You seem to be willfully ignoring the fact that it's dumb to constantly reinvent the wheel, but even dumber to simply walk and make squeaking noises and pretend you're a wagon. The best code is the sort that can be reused, or at worst adapted to other projects later on with minimal pain. If that's not an achievable goal, code should at least be as simple, small, and elegant as possible; this drastically reduces the number of bugs right from the outset, and makes those bugs (and future bugs) easier to spot and fix.

.... obviously you arn't getting it. the melee weapon would work, however I try to stay behind and toss as much grenades as possible before it could cast any spell.

Okay, so you need a clearer analogy here, then. But you're still on the wrong side of it. Because the person using the melee weapon would have to deal with a lot of hits before they finally succeeded, and thus their approach makes no sense vs. just lobbing grenades. This still isn't a great analogy, because the approach you're recommending is more the equivalent of throwing cats at the bad guy and hoping he endures enough scratches catching them to finally bleed to death.

Again, not a matter of preference. If you say, "I prefer to make my cake watery,"

I do not! (just joking, c'mon I HAD to say that.)

then you're not making cake, just eggy hot chocolate.

yes you are, just "watery cake" (another boring joke, but it's true, it's just how you look at things)

Complete relativism is a fool's headgame. There does come a point where a cake is no longer cake, no matter what it was intended to be. Sure, someone could say, "the cake came out runny", and could ask people to finish the cake, since what they really mean is "attempted cake". But it would not be cake, really, so if a person set out to make watery glop but merely called it cake, that wouldn't be attempted cake or even cake of any kind. Then they really have no right to call it cake or insist that others call it that either.

I won't respond to any more posts after this, unless I find it insulting. I feel you are trying to insultme and prove me wrong quite often, so I will try to end it no by saying "Done". So I am done discussing this topic.

I'm not trying to insult you, but merely correct you. (I don't think you've returned the favor, however. Your earlier comment about skill seemed to be intentionally snide.) Your stubbornness on sticking with what can only charitably be described as a bad habit is rather perplexing, and I'm baffled as to why you choose to defend the practice when there's clearly no justification for it--in this case or many others. You've managed to say several times that yes, it would work, but you've yet to rebut the simple fact that it would only work for the ultra-specific case for which it was made and couldn't be altered without significant effort.

These are the points you'd need to rebut in order to have a shot at maintaining your argument:

  • The many-var approach applied to even small cases requires much more work, particularly in copying and pasting and then altering text. To large cases the workload is vastly increased.
  • A bug in one line of code that gets duplicated to the other lines has to be fixed in every duplicated line, thus making bug fixes to these lines much harder.
  • It is easy to accidentally forget to alter a duplicated line, which creates obscure bugs.
  • Ultra-lengthy code is harder to understand, therefore harder to debug.
  • Hard-coding is difficult to adjust or alter.
  • Simple object references are more efficient than using giant switch statements to retrieve an object.
  • Lists can very quickly be searched, added to, etc., which makes them more efficient than many vars.
  • Some types of program logic are all but impossible with hard-coded vars. (Challenge: Create 50 hard-coded variables, assign them random values, then write an algorithm to sort them. Bonus points if you don't use a bubble sort, which is about the only feasible way to do this with hard coding despite the fact that it's the worst sort algorithm in the world.)

    All of these point to the same simple fact: With the amount of effort you'd put into getting any kind of close-to-real-world scenario to work using hard coding, the end result wouldn't be worth it. There are many different "flavors" of soft coding, and some of those are the wrong way to go too; but the ones that will work are clearly the correct solution. It's like solving a math equation; sure you could probably do it by trying every possible number, but it would take forever, and it wouldn't really teach you anything about solving equations, which could save massive amounts of time on the next problem. With programming, as in life, there really are wrong ways to do things; just because the method may work, if forced, doesn't make it right.

    It's not just that you prefer one way and I prefer another. It's that your way is absolutely wrong for over 99% of the situations that might come up in programming, and for others it's more of a quick-and-dirty solution. Quick-and-dirty has its merits, but only occasionally, and hard coding is just a subset of that anyway.

    Lummox JR
#18 Jan 2 2002, 1:36 pm
In response to Deadron (#16)
Deadron wrote:
That's not what he's trying to do, but at this point I'll remind Lummox of my upcoming BYONDscape article which encourages one to "stop arguing when the other person isn't going to change their mind" and "it's okay for other people to be wrong".

The important information has been communicated here for anyone interested/open to absorbing it, and it's time to move on...

Hrm. I didn't read this until after I posted my response, but it probably wouldn't have mattered. Although I agree there's a point at which further debate is fruitless, I don't think we've quite reached it yet. And I always wonder if I'm being unclear when someone doesn't rebut my points; usually that becomes more apparent later on.

Don't worry, though; I have no intention of letting this drag out like the .bmp-vs.-.png debate I had... er, tried to have... with FIREking. And if Geo really isn't going to respond further, then I guess my intentions are moot anyway.

Lummox JR
#19 Jan 2 2002, 3:07 pm (Edited on Jan 2 2002, 3:15 pm)
Attention.
Redirects post magically ON TOPIC

OK now I'm sorry Geo but that idea with hard-coding individual vars is HIGHLY ineffiecient for my system. Here's a summary.
You go to the deeds office and pick a plot number. You fund the number by surveying plots around the POH area. Then it checks if a deed already exists for that plot. If not you are asked if you want to buy it. Now here is the problem I don't know how to get it to BUY the land. Every POH area has a few vars. They are ISOWNED (not who the owner is. Why later.), price, and size. Now the names are
plot1, plot2, plot3, ... Now I know I can code this by having a million lines with area info hard-coded

I want to know if I can get this working so that it access it kind like this-
wealth =- plot[plotnumberbuying].price
Also how would I check if a person is in an area.
Because when you build it checks the plot(if any) you are in. Then allow you to build. This is using the same...

if(area.plotnumber == deed.plotnumberowned)
^? ^in area code ^ in deed code
^ check area stat
Also check if in a plot area.
In short I just want to check if you are in a POH plot area and if that areas variable maches a deeds variable.

Also you are able to trade/sell deeds

Question on Keys.
Lummox JR using the key code you gave me how would I make a copy of the key?
Page: 1 2