Some progress on BYONDclipse, any help from experienced developers?

Page: 1 2 3
ID:1754244
 
Jan 4 2015, 2:06 am (Edited on Nov 28 2015, 2:36 am)
http://i.imgur.com/S5LWfEi.png

It's not finished yet, but so far it's showing promising results. I was hoping to release a version after the content assist code was finished, so that others could benefit from the DM editor.

A map and icon editor would still be needed, and the use of this software requires a change to the way you'd write code (namely you have to include files manually, which is actually a good thing because then you can decide the order of inclusion).

I'm posting this here in the hopes of finding others with Java skills to help me develop the project. I'm prepared to upload what I have to Github if there's enough attention (though I fear it'll fade into obscurity).

Current features:
- Project build. Calls up dm.exe (fixed location based on hard-coded constant, no configuration yet) and compiles the game.

- Problem markers. If there are errors or warnings markers are created accordingly and you can double-click on them to go to the appropriate file.

- Syntax highlighting. I've tested various permutations and it should be entirely up to specs now including the escape character (\) in strings and code blocks in strings ("[blah]").

- Partial auto-completion. You can use CTRL-Spacebar to bring up a list of suggestions.
Local variables are automatically scanned.

I've converted the DM Reference to XML format and this is used (hard-coded file) to provide suggestions for built-in procs and verbs.

The current object path is used, so if you're in a /mob/proc/blah() it will show stuff from /mob, /atom/movable and /atom (note that parent_type does not work as of yet so the /atom/movable bit is hard-coded).

- Light-weight. I've tried to keep things simple and light so that others can navigate the code a little easier.

- Tested with SS13 build. Once the includes have been moved from the .dme to a loose .dm file in the root of the folder it compiles properly, though due to the time it takes you do have to wait a bit. It's probably best to abort compilation and retry every time a build occurs to prevent this delay from being too much of a nuisance.

EDIT: The project is now available on Github. https://github.com/nullquery/BYONDclipse https://github.com/BYOND/byondclipse
Jan 4 2015, 6:48 am
What's the benefit of BYONDclipse over Dream Maker? What's the ultimate goal? Autocompletion seems like it would neat.
Jan 4 2015, 6:58 am
In response to Sir Quizalot
Sir Quizalot wrote:
What's the benefit of BYONDclipse over Dream Maker?

Are you serious?

What's the ultimate goal?

It would be nice if DreamMaker could be replaced altogether. It could lead to dm.exe (or just 'dm' for Linux/Mac users) being the only thing that needs to be maintained.

Autocompletion seems like it would neat.

It's called content assist, and it's a common function in many IDE's. That's part of the reason for doing this.

The other part is CTRL-SHIFT-R functionality. This can be used to quickly open a resource without having to go through every file or perform searches on direct paths.

Screenshot of this in action: http://i.imgur.com/mzZM04b.png


IMO what's currently there is sufficient as a starting point to develop a proper IDE to replace DreamMaker. It needs further development which is why I'm sharing this with everyone; to inspire developers to develop this further.
Jan 4 2015, 10:34 am
I wish BYOND had more of an attitude like yours.

You create something and then you open source it for others to improve upon.

I imagine if DM was open source, people like you would have collaborated to create a more efficient, modern engine by now.

I am interested in this little editor, because Dream Maker seems like it could be improved in alot of ways, but I am not sure if I could ever offer any true assistance, since I don't really have any experience in application development.

I wish you and anyone else who picks this up the best of luck though, because I think BYOND could really use a better IDE.

Regards,
Orange.
Jan 4 2015, 11:53 am
Sure this would give BYOND a small boost, considering most have windows and the language is still the language? Certainly will give people something to compare Dream Maker to. If it comes out as the web client becomes stable it would bring in new developers. I'm for this to try and include a unit test generator.
Jan 4 2015, 12:03 pm
By all means help out with the project! I do recommend however that we should focus our efforts on getting a stable code editor first before focusing on stuff like unit tests and the like.

Right now it's a shoddy replacement for DreamMaker at best, as it still lacks a lot of functionality that even DreamMaker has -- namely no map, skin, or icon editor.
Jan 4 2015, 9:36 pm
I think this is a great idea, because, ultimately, we want BYOND to be fully cross-platform with the web-client (including a CEF-based client/server for testing & single-player games.. we'll provide that at some point). Since the DM IDE is such a large project and somewhat standalone from everything else, it's unlikely we'll do that ourselves anytime soon.

Both the icon- and map-editor formats are somewhat self-explanatory, although we can provide assistance if you need it. I wouldn't worry about the skin-editor since I expect that format to be superceded by the javascript-based skins in the future.

I do know that others have started similar ventures in the past so you might want to search for that and possibly get in touch to see if there are collaboration opportunities there.
Jan 27 2015, 8:15 am
No more having to type in a terminal to edit code on a unix platform you say? Keep it up. I'm ready to throw the money I don't have at the production of this! It really looks good. And man, the intellisense. It gives me goosebumps knowing I no longer have to press F1 to look up the name of a function I have touched in years.
Jan 31 2015, 11:29 am
Hm, the license, means I can add features then sell right?
Jan 31 2015, 11:46 am
In response to Sir Quizalot
Yes. But in turn you must release the changes you make (to which the end-user can simply build the project from the source instead of buying it).
Jan 31 2015, 3:01 pm
Yes. But in turn you must release the changes you make (to which the end-user can simply build the project from the source instead of buying it).

Yes and no. You don't have to release the source code of anything that uses dynamic linking to extend the functionality of an existing project.

For instance if I download a build of Qt and then create a subclass of QMdiArea that extends its functionality, I'm allowed to keep the source code private. I only have to release modifications to the source code that generates the compiled product with said license.

So long as my source code is maintained in another unit, I'm more than within my rights to keep it private. There's a common misconception that LGPL/GPL/MIT etc. can't be mixed and matched. There's also a common misconception that licensed and open-source software licenses "infect" your project. It's simply not true.
Jan 31 2015, 4:14 pm
Also, some information for anybody wanting to develop a DMI editor and a DMM editor:

The DMI format is pretty simple. Download TweakPNG's source code on Github to take a look at how PNG files are structured. You can also get a build of TweakPNG there and open up a DMI file.

Chunks:
IHDR: PNG Image header, width, height, bit-depth, structure format, interlacing data
PLTE: palette data. Self-explanatory.
tRNS: transparency data for palette colors.
zTxt: Stores BYOND's specific metadata as a compressed comment. The Description keyword is the one we care about

#BEGIN DMI
    version = 4.0
    width = 32
    height = 32
state = "state name"
    dirs = 1
    frames = 2
    delay = 1,1 //only present if there's multiple frames
    loop = 1 //only present if loop is not 0
#END DMI


I'm not sure about rewind or movement state markers, because I don't use either.

After this point, you really shouldn't care about what's in a DMI. It's literally just a PNG file with metadata in the description.

To duplicate the features of the DMI editor, all you would need is the IDHR block to get the information needed to read the palette, then jump to the PLTE block, then to the tRNS block, and finish off with the zTXt block to construct the states.

Frames are packed from top left to bottom right. frame 1: SOUTH, NORTH, EAST, WEST, frame2: SOUTH, NORTH, EAST, WEST, etc.

I haven't done enough experimentation to figure out the exact rules by how it chooses a size for export for the spritesheet. It seems to prefer exponentials of two.



DMP format is also pretty simple to do if you have access to a language with const classes/structs.

DM.exe will spit out a series of type strings, variables and procs in XML format. All we care about are types and variables. You can ignore the procs. Parse them and sock away everything that gets generated in whatever structure you want.

The map structure should be pretty self-explanatory. It's the map pops that are going to be the thing you need to pull off properly.

Map pops need to be const types. This means that initializing a new map pop that has identical properties to another map pop will return the already-initialized one.

If you can get that done, all you have to do is iterate through whatever arbitrary structure you create to represent maps in progress. When map export is finished, you simply destroy the map pops you have created.

In order to cut down on compilation time, though, you will ideally want to keep the map pops in memory. Trouble with this, is that it's going to eat some serious memory.

The DMM format needs a redesign with Revision Control in mind. Right now, there's a lot of worst-case scenarios when it comes to change vectors on DMM files. Changing a single tile can actually result in large swaths of the file having to be regenerated. There's no reason that a new DMM editor couldn't use a newer/better format and generate a DMM in the background as a pre-build step.
Jan 31 2015, 4:18 pm
In response to 8BitParagon
Additional reading for the .dmi format. Might be out of date in some contexts.
Jan 31 2015, 4:34 pm
In response to LordAndrew
LordAndrew wrote:
Additional reading for the .dmi format. Might be out of date in some contexts.

Either I didn't understand what Lummox wrote at all, or all of that is no longer relevant. DMIs can be loaded as a normal PNG using a number of free tools. All you have to do is navigate to the palette and ztxt blocks to be able to work with them as parameterized spritesheets. Reading the files manually like that is no longer necessary.
Jan 31 2015, 6:38 pm
I already wrote a parser for DMI files in Java, but I haven't released it because the only person that seemed to show any interest in this was Tom...

Though I haven't heard anything on my feature request either, so I guess it's up to us to develop a code analyzer (hah! that wouldn't turn out buggy)

And there's this:
Sir Quizalot wrote:
Hm, the license, means I can add features then sell right?

I released this with the intention of gathering people that would help with the project. Preferably people who know more about code analysis than I do who could fix up the content assist functionality.
Feb 1 2015, 6:04 pm (Edited on Feb 1 2015, 6:11 pm)
Ha, that would lead me to ask how much do you know, or rather you don't know. I like to consider effort to reward before I make an effort, right now it seems some would profit from your free effort and you get glory text and maybe even criticism. Leads me to believe this is a side hobby project and should be treated as such, unless a slightly different purpose is created for it, either way I'm interested. #When Do We Want it Now Mindset
Mar 11 2015, 6:19 pm
I and a few friends have a lot of experience with the BYOND formats and network protocol and I have been working on something in QT similar to what you have going on here. I'm working on a lexer for DM atm because why not. Thinking about retargeting DM from the byond executable format(which is pretty gross btw) to something like LuaJIT bytecode.
Mar 12 2015, 11:45 pm
-_- this post made me drool.
I wish I could halp.
My coding level isn't over 9,000 just yet tho.
Mar 13 2015, 1:22 am
I'll make a few pull requests over the next week on this, to tidy up the repo (you've got binary output and local settings files in there which you don't really want to be including) and convert the projects to using Tycho:

https://eclipse.org/tycho/

This would allow the project to be easily built with automated tools like Jenkins, have a controlled release cycle, automatically publish releases to an Eclipse update site we operate etc.

This should all make the project more accessible to people, both in terms of users and in terms of contributors.
Mar 13 2015, 1:25 am
Possibly we'd like to house this project under the BYOND organisation in github also?
Page: 1 2 3