Otherwise you would be insane to think that compiling after every small change is going to somehow make your function better than writing it all at once and compiling it later.
some people have bad PCs.
King of Slimes's PC restarts absurdly frequent, so he compiles like the wind.
I find that the best programming style is one in which things are very divided and flexible. That way, if there is a problem, it can be easily identified (especially if you have debug mode on) and fixed without making many changes to the code. I over simplify things in code and I really do tend to forget the basics sometimes, but everything works efficiently.
King of Slimes's PC restarts absurdly frequent, so he compiles like the wind.
I have actually found multiple solutions:
don't compile, but use the save (CTRL+S) function to save the file you're working on;
when editing multiple files at once, saving them all at once using Save All (CTRL+L I think) would work better
since my DreamMaker crashes a lot when compiling SS13 (about once every five times), write a batch file to do the compiling for you by using the new dm.exe and the 'pause' statement (so you can read your compile errors and the lines they're on).
This seems to work rather well, except it still takes some time before it actually finishes compiling. This saddens the Data.
My request is to put this on the list: I think something fishy may be going on here, and perhaps looking into it will lead to a bug or an inefficient system that is causing the extended time.
King of Slimes's PC restarts absurdly frequent, so he compiles like the wind.
I have actually found multiple solutions:
don't compile, but use the save (CTRL+S) function to save the file you're working on;
when editing multiple files at once, saving them all at once using Save All (CTRL+L I think) would work better
since my DreamMaker crashes a lot when compiling SS13 (about once every five times), write a batch file to do the compiling for you by using the new dm.exe and the 'pause' statement (so you can read your compile errors and the lines they're on).
This seems to work rather well, except it still takes some time before it actually finishes compiling. This saddens the Data.
My request is to put this on the list: I think something fishy may be going on here, and perhaps looking into it will lead to a bug or an inefficient system that is causing the extended time.
since my DreamMaker crashes a lot when compiling SS13 (about once every five times)
I've never once had any crashing issues with SS13 code. This is probably a local issue and you should report it in the bug reports forum (with a stack trace or so).
I get crashes during compiles myself if I've had the Dream Maker open for a while and have done a large number of compiles. Usually it occurs when I get a number of errors, but it also occurs if I've had a number of errors and then compile successfully several more times.
I suspect it's a stray pointer that occurs as a buffer overruns or something. However, without any way to predict when it will happen or why exactly it happens, I haven't yet been able to isolate a workable test case.
all the icons you coded in a file are stored into the rsc. So typically if you had an all coded game with no icons whatsoever, then you get instant. But for a game with icons, it has to store the code from those icons.
Icons take the most(3/4) of the file size. For one pixle takes so much since the code must draw its coordinates and then display every line of code which represents a block.
all the icons you coded in a file are stored into the rsc. So typically if you had an all coded game with no icons whatsoever, then you get instant. But for a game with icons, it has to store the code from those icons.
News flash: the .dmb file does not implicitly contain any information about the icons apart from their file reference.
Icons take the most(3/4) of the file size. For one pixle takes so much since the code must draw its coordinates and then display every line of code which represents a block.
At most the .dmb contains a reference to the icon, but that's about it -- and that does not involve lots of calculations, but only a starting point in the resource file where the icon starts.
The resource file for SS13 is generated very easily, but the compiling of the map and code are what takes so much time. I'm guessing the map takes some time to compile because it contains quite a bit of instances, and the SS13 source-code is riddled with bad habits and lengthy instructions because it's has been decompiled.
all the icons you coded in a file are stored into the rsc. So typically if you had an all coded game with no icons whatsoever, then you get instant. But for a game with icons, it has to store the code from those icons.
News flash: the .dmb file does not implicitly contain any information about the icons apart from their file reference.
Icons take the most(3/4) of the file size. For one pixle takes so much since the code must draw its coordinates and then display every line of code which represents a block.
At most the .dmb contains a reference to the icon, but that's about it -- and that does not involve lots of calculations, but only a starting point in the resource file where the icon starts.
The resource file for SS13 is generated very easily, but the compiling of the map and code are what takes so much time. I'm guessing the map takes some time to compile because it contains quite a bit of instances, and the SS13 source-code is riddled with bad habits and lengthy instructions because it's has been decompiled.
-- Data
illegal decompilation? o.o;
who did it D:
last KoS talked to Hiead, (1 year ago or so) he said it'd take too much work... did someone find the balls to make it?
because it contains quite a bit of instances, and the SS13 source-code is riddled with bad habits and lengthy instructions because it's has been decompiled.
Not because it was decompiled, but because the original developer isn't a good programmer.
because it contains quite a bit of instances, and the SS13 source-code is riddled with bad habits and lengthy instructions because it's has been decompiled.
Not because it was decompiled, but because the original developer isn't a good programmer.
how did anyone make a byond game decompiler without being banned? O_o
I had this discussion on #bay12games at one point. Irrelevant DF bits trimmed out, here goes:
[22:07:42pm] <Delamore> So I haven't stayed up to date with BYOND news, what ever happened to the decompiler scare?
[22:08:44pm] <JT> It exists. Hobnob has one. Slurm has one. I think our Rick is BYOND's Slurm.
[22:08:53pm] <JT> Neither of them share. =)
[22:09:45pm] <JT> In any case, decompiled code is readable but it doesn't write your game for you. No comments, untyped variables, etc.
[22:10:52pm] <Delamore> At least hobo and slurm aren't spreading it
[22:11:00pm] <Delamore> But if one can work it out, others will follow
[22:11:56pm] <JT> The good part is that the people unscrupulous enough to want to rip off source code are usually the ones unskilled enough that they can't write a decompiler.
[22:12:27pm] <JT> The people who are skilled enough to write decompilers did it out of necessity in light of certain programs being lost to history.
[22:12:42pm] <Delamore> Heh, I asked two people I know with decompilers to help me with something for a game I'm designing
[22:12:43pm] * Momaw whacks JT with a scruple
[22:12:48pm] <Delamore> Both were tight mouthed
I get crashes during compiles myself if I've had the Dream Maker open for a while and have done a large number of compiles. Usually it occurs when I get a number of errors, but it also occurs if I've had a number of errors and then compile successfully several more times.
I've never had Dream Maker crash on me once. It's always compiled, and it's always been reasonably quick. Then again, I'm not working with 1000x1000 maps and 20,000 lines of code.
some people have bad PCs.
King of Slimes's PC restarts absurdly frequent, so he compiles like the wind.