In response to Chessmaster_19 (#18)
You shouldn't have to view the code of two procs at the same time. They should be independent. You only care about inputs and outputs.
I often open a notepad and toss something into it to refer to while working elsewhere. It works pretty well for me since DM doesn't have MDI. I'd probably still do it even with MDI because I can stick a lot of proc declarations in a notepad window. I don't often work on 2 sections of code at 1 time but sometimes I do and MDI would help there.
In response to Obs (#20)
Obs wrote:
You shouldn't have to view the code of two procs at the same time. They should be independent. You only care about inputs and outputs.

Not all procs' should be independant. For example: Levelup
You would usually call a EXP Check then if the EXP is equal to or greater than Maximum Experience call the LevelUp Proc.
In response to Obs (#20)
Obs wrote:
You shouldn't have to view the code of two procs at the same time. They should be independent. You only care about inputs and outputs.

I work with separate pieces of code all the time.

My structure says my mob variables and what not are in one file, ny NPC's and their stuff is in another, my interface code is in a third, general world procs are in a fourth and client control is in a fifth. I'm constantly bouncing back and fourth between one, two even three or more blocks of code at once.

The bigger projects get, the more organised they need to be. Organisation is more important than ease of editing, you can't edit a proc if you can't find it. Personally, having a vertical splitter to view two or more segments of code at once would be very handy.
In response to Inuyashaisbest (#22)
Well, there's just a lot of back and forth arguing here:

"It'd be useful"
"No it wouldn't"
"I have a different method"
"It'd be useful"
"No it wouldn't"
ect.

I think the point here is that it'd be useful to some people, even if it's not everyone, and I think it'd be useful to a significant number of players to consider adding it.
In response to Chessmaster_19 (#24)
You're quite right. But that's how arguments are, what do you think we should do instead? :P

Chessmaster_19 wrote:
I think the point here is that it'd be useful to some people, even if it's not everyone, and I think it'd be useful to a significant number of players to consider adding it.

It wouldn't make any difference for players. :P

Anyway, as has been said this would probably require a notable amount of work to rewrite things in the Dream Maker code and would take time, which I rather be spent on BYOND itself anyway. This kind of stuff is more of an IDE thing yes, as has been said. We have a command line compiler now so we have no reason not to make our own IDEs if we want special features and as such.
Similarly, you don't even need to use Dream Maker to code. So for now if you really wanted these features you could use any common text editor that has the special features you want to edit .dm files, you only need Dream Maker (or dm.exe) to compile. You won't get syntax highlighting off the bat, but you'll get anything else.
In response to Flame Sage (#16)
Yeah, I wish he would too, but as I'm not willing to make it, I don't want to really complain about the length of time it's taking him to do so :P
In response to Obs (#13)
You mean something along the lines of the hellishly horrible intellisense? Hell no.
In response to Kaioken (#25)
Of course it would make a difference to players if the developers design the games better, as the players then have a better game :P
In response to Jamesburrow (#28)
Hehe. But in actuality this wouldn't make developers design games better, I'm all out for things that can do that kind of stuff (hence I said I prefer the staff worked on BYOND itself rather than Dream Maker convenience features). This would just make it possibly easier by being more convenient to some developers, but it wouldn't really change the outcome of their code. :P
In response to Kaioken (#29)
It could. If it is easier to code, chance are the developer will have an easier time doing a better job ;)
If it's a hassle to code, more developers will do just a half-arsed job and produce a cruddy game.
Granted, many "developers" will anyways, but at least we can TRY to decrease the ratio a little :P
In response to Kaioken (#25)
Kaioken wrote:
You're quite right. But that's how arguments are, what do you think we should do instead? :P

Well, it's really not the argument itself that I'm trying to critique, it's the topic of the argument. Arguments are really the point of posting a suggestion on here, but if they're just pointless useless arguments, the topic will probably get locked. I was trying to say that there's no point in arguing about whether or not it would be useful. It would be useful to some. There are better things to argue about.

It wouldn't make any difference for players. :P

Right. Players was a mistype. I meant developers. If I wanted to keep defending a mistype, I could state that what developers aren't players, but there's no point, it was an error.

Anyway, as has been said this would probably require a notable amount of work to rewrite things in the Dream Maker code and would take time, which I rather be spent on BYOND itself anyway. This kind of stuff is more of an IDE thing yes, as has been said. We have a command line compiler now so we have no reason not to make our own IDEs if we want special features and as such.

Now, I have no knowledge of compiler coding. So, I'll just apologize right now for arguing out of ignorance, but I'm gonna do it anyways.
I personally have always assumed that the majority of a compiler consists of the actual compiling, converting the code into something the computer can read, error checking, ect. It seems to me that it wouldn't take a complete overhaul of the DM code to implement this idea in its simpliest form.

As for whether or not it would be worthwhile for BYOND itself, which is of course the most important question, I believe it could be. As Jamesburrow said, help for developers means better games. Also, I believe helping out the developers helps BYOND in general, for example:
1) New Developers. I've found that some BYOND coders can be a little... elitist at times. (No one get offended, please. I'm not naming names) The jump from player to coder is a huge gap, and I think anything that can be done to help encourage players to make the leap would be good. The more user-friendly the DM compiler is, the easier time players will have becoming good developers.

2) Developers will be able to find "continuity error" in their code easier. While basic coding can be learned relatively fast, it takes years of experience to be able to think through a thing of code and think through possible ways that that code can be defeated by other chucks of code running symultaneously. (Even I'm not good at it) If developers can compare two sections of code side by side (or one on top of the other, as it may be), loopholes would be easier to spot when coding, or to find later when you get an error. If you want to talk about improving how well BYOND games run, helping to eliminate many runtime errors would be a great start.

3) Developers would be able to write more complicated code a little easier. More games might use things like html and browser based interface (requiring Topic() procs) and less on the same old popup boxes.

Anyways, these are just ideas that came to me right now. The point is, benifits to the developers would be benifits to BYOND, so saying that you would rather have the time spent on "BYOND itself" is less of an issue.
In response to Inuyashaisbest (#22)
Those procs are independent.
In response to Obs (#32)
Obs wrote:
Those procs are independent.

independent = relies on self
dependent = relies on outside

So a player can call it whenever he wants? hey Free levels just type LevelUp! Wouldn't really be a fun game now would it?

anyways back on subject, yea this should be made into a dm or ide thing but to be honest I think Crashed quit working on the IDE. :/
In response to Inuyashaisbest (#33)
Inuyashaisbest wrote:
Obs wrote:
Those procs are independent.

independent = relies on self
dependent = relies on outside

So a player can call it whenever he wants? hey Free levels just type LevelUp! Wouldn't really be a fun game now would it?

He has some sort of point. You should try to at least make it so that the underlying functions can be used without the dependent functions.

George Gough
In response to Inuyashaisbest (#33)
You're missing the point. Being called from isn't being depended on.
The point is that those 2 procs don't rely upon eachother to run; they don't need each other to run (although, you could say that EXPCheck() depends on LevelUp() because without the LevelUp() proc it wouldn't compile). You can run one without calling the other. Otherwise if LevelUp() could only ever run successfully right after EXPCheck(), you would just put it's code in the end of EXPCheck() and there wouldn't be a point to making them separate.

For example - LevelUp() is not dependent on EXPCheck(), because it can run without the latter ever being run or even without it existing. So, separating it from EXPCheck() is useful, say, in the case of a reward for the quest, you could give the player a reward of a free LevelUp() without needing any exp by calling that proc directly, "alone", independently. If you had the level-up portion incorporated in the EXPCheck() you'd need to do ugly, bad hacks with changing exp to an appropriate number so the proc let's the mob level up, then undo your changes to exp.
Page: 1 2