Yeah I have that lol, the main problem was using T.loc.x and not T.x why is that silly though to do it that way ?
You shouldn't have that code included. By default, when an atom is created, the first argument to new Type (Args...) should be the initial location, so you rarely need to set loc in New().
For a turf T, T.x is the turf's x coordinate, whereas T.loc.x is the x coordinate of the area containing the turf, which is the x coordinate of the lower-left-most turf contained in the area. | |
Yeah I figured out the second paragraph the first time you said it..lol
Sorry forgive my ignorance on your first paragraph, based off what you said I'm still not sure how i'd place it's location without using the Obj's New() | |
Without overriding New() for anything, if you do new /obj (t), where t is some turf, the new /obj will be initialized with its loc = t. This happens by default.
If you overrode New() to do this: obj/New(X, Y, Z) then you broke the default behavior and new objects can't be placed in the default way. What you have been showing in your turf/New(), turf/etc/New() This is correct, but it doesn't work because you broke obj/New(). What you have required yourself to do, by overriding obj/New(), turf/etc/New() This is not how it should be. | |
Ohhhh!! wow cool, didnt know that thanks!
But if i wanted random properties like quality/hardness/etc to be assigned on the objects creation then i'd have to override the New() right? | |
Right, but if you want to pass arguments other than the initial loc, you should position those arguments after the first one, like so:
new /obj (initial_loc, extra, stuff, here) | |
But if i wanted random properties like quality/hardness/etc to be assigned on the objects creation then i'd have to override the New() right? Yes, but the default first argument for New() is "loc". If you want to add additional arguments, you will want to preserve the default argument. This is also a source of bugs in many, many BYOND games because for some reason people seem to think that if you override New(), the default action will not be called. This isn't the case. Initializing new objects has behavior that cannot in any way be disabled. For instance: obj Most people would naively think that removing all the objects from the client's screen would delete them, but if the first argument of new() is an atom, the movable will be placed in the contents of the atom passed as the first argument. This happens before atom/New() is even called on the object. In the above example, what winds up happening is the screen object is stored in mob.contents, causing it to not be deleted from the character when the client saves. This creates a leak that will get progressively worse every time the player is saved or loaded. Almost every major anime game in existence right now suffers from this problem. So yeah, understanding the way that New() works and understanding garbage collection at this phase will save you a lot of trouble. | |
Ahhh gotcha, makes more sense now.
How did you guys learn all this stuff? just alot smarter than your average noob dev like me? I feel like if we had a Wiki with alot of this stuff clarified better and categorized better then doing forum searches and google searches I would ask alot less dev help questions. Nonetheless I really appreciate you guys taking the time to help!! | |
Read the DM Guide, read the DM Reference (F1 in Dream Maker), read tutorials, read good code. In that order.
The DM Reference is probably the most useful of all of them. It's the most up-to-date source of information on most every little thing you can do. The "New proc (atom)" entry explains the default behavior of atom/New() and the loc argument. It should've been your first place to check if you've been having issues with New(). | |
I don't know about Kaio, but I got my start in 2001. Gughunter, Lummox, Lexy, Tom, Dan, Deadron, Zilal, Skysaw, and Leftley pretty much told me what they knew whenever I had questions. Most of their style of teaching was answering direct questions for "I've gone wrong somewhere", and deflecting my questions for "How do I do this?" and telling me to read more/just try it myself and see what I come up with.
Most of programming is just understanding the tools at your disposal and figuring out how to apply those tools to solve small problems. Once you can solve small problems, you can start chaining together small solutions into bigger solutions. And so on. Most of the tools at your disposal are simple instructions. They take a value and transform it into something else. If you deeply understand the small, simple instructions you can figure out how to transform data from one thing into another through a series of multiple steps. It's all about logic. And unfortunately, logic isn't something that you can really be taught. You have to understand a lot of little things in order to be able to apply logic. Logic is very much a combination of experience and analysis. So best advice is to keep an eye on the guide and ask clarifications here until you start to grasp the small things. Don't lean too much on your understanding when you have problems (This can lead to arrogance or the inability to address small misunderstandings that will snowball into turning into Falacy/AvidAnimeFan Mk.II). Always try to secondguess your own understanding and avoid being too invested in any one particular train of thought. Refining your understanding often requires shunting temporarily wrong explanations into your overall understanding until which time you can find contradictions that force you to replace the explanation you previously thought was true. Asking questions isn't bad at all. It results in exactly this kind of discussion, and actually discussions like this do benefit people like me and Kaio, where we all wind up discovering new stuff and building on our own understanding. I mean, just a few months ago someone was having trouble with a saving system and I managed to learn something that I didn't know, and it was leading me to offer some flawed advice periodically around here. Great places to start are to peruse the guide for things that might be useful in the moment, and finding people around these parts that you like to talk to and pick their brain on implementation strategies. Don't focus too hard on "the best" way of doing things though. Work it out for yourself and seek help where it becomes obvious there's a flaw with your approach. You aren't going to master the language all at once. It's going to be a long incremental process, and no guide is going to be able to teach you everything you need to know from the outset. TL;DR: You are doing fine, Mitchy, and nobody's gonna call you out for asking "dumb" questions unless you are walking in with a question that implies you aren't interested in doing your own code-writing or thinking. Even then, especially with a question like this, I can't call it dumb because it's so commonly misunderstood by the community at large. It's a good question, and it's one that is best addressed as early as possible. | |
Mitchy said:
Wondering if New() on turf has a problem with src.loc vars? not initialized yet? Damn! I had a hunch you were confusing turfs and areas when you said that; Kaiochao beat me there. Glad you got your issue figured out though. Best of luck. | |
I think you meant that to say locate(x,y,z). Although you don't need to do that, since in a turf src is the same as locate(x,y,z).
| |
Ter13 wrote:
TL;DR: You are doing fine, Mitchy, and nobody's gonna call you out for asking "dumb" questions unless you are walking in with a question that implies you aren't interested in doing your own code-writing or thinking. Even then, especially with a question like this, I can't call it dumb because it's so commonly misunderstood by the community at large. It's a good question, and it's one that is best addressed as early as possible. So much this. A good programmer knows when to ask questions and admit they have more to learn, because nobody knows everything. I'm still being reminded of things, or learning them for the first time, from power users who do things with savefiles and other features that I don't often touch. | |
Awesome replies, thank you guys. I'll definitely keep at it!
Also, Kaiochao was right -- should read reference carefully first lol I dont think it would have solved my issue because I didn't know that New() will overwrite the default New() proc. So I learned more than 1 thing from 1 question! :) Here's it in action!  Now to figure out how to do clumping of grass and flowers to make it look a bit more natural.. lol | |
Depends on how natural you want to take it. Your grass tile looks very good as-is, so I wouldn't be too concerned about that.
One way to improve on the natural look is to take the states you have with the plants and objs, and make several different choices to pick from. This is the simplest route to take and will pay off the best in terms of performance, with a middling improvement in appearance. Adding a minor pixel offset nudge to the plants will further improve appearance, pulling things away from a grid-like look. If the plants are objs, you may find that they're an unnecessary performance expense; it might be more convenient to add them as overlays. With pixel offsets this may be more problematic if you do it a lot, as you could end up with a crapload of unique turf appearances, whereas objs work differently but you still have to deal with the small cost of the server traversing through them. | |
which would be the reason they weren't being placed properly before, and probably should've given some runtime errors.