In response to Obs
Obs wrote:
Uh no that can't possibly be what you meant.


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.
In response to Falacy
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.
In response to Eternal Desire
Eternal Desire wrote:
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.

    -- Data
In response to Android Data
Android Data wrote:
Eternal Desire wrote:
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.

    -- Data

    'new' dm.exe? link please?
In response to Android Data
Android Data wrote:
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).
In response to Eternal Desire
Eternal Desire wrote:
'new' dm.exe? link please?

It's not that new anymore. Use the search, or even search in your BYOND directory.
In response to Android Data
You shouldn't be crashing just from a compile, no matter how crappy the source code is.
In response to Obs
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.
In response to Kaioken
Kaioken wrote:
Eternal Desire wrote:
'new' dm.exe? link please?

It's not that new anymore. Use the search, or even search in your BYOND directory.

the dm.exe i have installed? if not, link please cause i didnt find anything.
In response to Eternal Desire
Excuse me friend, but I think I've missed the point of quoting text that answers your own post, eh?

Eternal Desire wrote:
the dm.exe i have installed?

Kaioken wrote:
search in your BYOND directory.

What do you think?

if not, link please cause i didnt find anything.

Kaioken wrote:
Use the search

What do you think? Searching isn't frickin rocket-science, people.
In response to Popisfizzy
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.
In response to Mr.Kitten
Mr.Kitten wrote:
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
In response to Android Data
Android Data wrote:
Mr.Kitten wrote:
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?

if so give me a knife :D!
In response to Android Data
Android Data wrote:
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.
In response to Slurm
Slurm wrote:
Android Data wrote:
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
In response to Eternal Desire
Eternal Desire wrote:
how did anyone make a byond game decompiler without being banned? O_o

The two people who each have developed a decompiler have not given theirs out.
In response to Eternal Desire
Eternal Desire wrote:
how did anyone make a byond game decompiler without being banned? O_o

byond staff couldnt care less about ripping, have you seen the hub?
In response to Eternal Desire
They can be trusted.

George Gough
In response to Eternal Desire
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
In response to Jtgibson
Jtgibson wrote:
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.
Page: 1 2 3 4