Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - IsmAvatar

Proposals / Re: Script Editor Features
« on: February 23, 2011, 02:06:49 pm »
6: Please see Polygon#4
7: Code folding is already planned.
7a: Wut?
8: This is an already existing LGM feature request, and it would extend to all maximized resource frames, not just code editors.

Issues Help Desk / Re: Help with GM's instance ID system
« on: February 21, 2011, 03:43:41 pm »
Interesting. I accept your theory, then.

Issues Help Desk / Re: Help with GM's instance ID system
« on: February 21, 2011, 12:58:21 am »
Unless you're using a non-standard definition of ID, I do not believe your theory holds.
Create a room with a non-persistent instance. Record the instance ID. Leave the room for another room, and return. Record the new instance ID. If the two IDs do not match, your theory is disproved.

Issues Help Desk / Re: Help with GM's instance ID system
« on: February 20, 2011, 07:51:27 pm »
I'll brief you on the little stuff I know:

ID's start after some high number like 100000 so that they don't conflict with object IDs. This allows you to do things like:
object.x = 5
instance.x = 10

On game restart, all the instance IDs are bumped up, so that the lowest instance ID is higher than the highest instance ID of the last run. Because of this, it's bad practice to reference instance IDs directly, or to try to hang onto them after game restart.

I can't tell you about the behavior of persistence, but it's very easy to inspect and find out for someone who has a copy of Game Maker installed.

Proposals / Re: Script Editor Features
« on: February 20, 2011, 07:27:14 pm »
2: What you are describing sounds like an aspect of Code Formatting. It's already in consideration for the later stages.
4: Good idea for the later stages.

Too lazy to make one. Get me a Java code monkey to write one. Until then:

Please see Fede-lasse #4

Proposals / Re: Script Editor Features
« on: February 20, 2011, 12:44:12 pm »
I have some suggestions. Note that they should be options, not enforced.

1. When you copy and paste a code from somewhere, the editor automatically formats the code according to the rules set by the user in LateralGM.

2. Allow the user to use tabs in the auto-formatting script rather than spaces.

3. When you select several lines of code and start from the longest line, the editor shouldn't violently jump all the way back to the left when moving the mouse out of the long line. What if I just wanted to select a snippet of the code in that line? This happens all the time in GM. It should only move left or right when you move the mouse to the side of editor window. Moving up and down is still done the traditional way, though.

4. The code editor checks the syntax X seconds after the user stops typing.

1: This is a later-down-the-road suggestion. We'll consider it.
2: Probably will be implemented as an option when we get there.
3: I think we resolved this by allowing the caret to remain in virtual post-line space, but be drawn at min(caret.x,line.length).
4: Sounds easy enough.

Some of these are LGM, some are code editor, some are a combination:
  • Expand/Collapse brackets (), {}, [], begin/end
  • Fix indenting
  • Refactoring(Rename variable, Rename Script, Extract Method)
  • Auto-complete - see MonoDevelop for ideas(for instance, in MD "Case" matches "camelCase", etc.)
    • If the above situation about camelCase is accepted, then some customization would be nice(camelCase vs underline_separated, etc.)
  • Breakpoints
  • Tab indents selection(in GM, tab doesn't indent selection, it replaces it)
    • Shift+Tab unindents selection(or current line, or whatever)
  • Script documentation support(Like /** @argument0 Instance to receive foobar */)
  • Code style editing(replace begin/end by {} and vice-versa, remove all then statements, add ; to the end of lines where a ; is implicit, remove all unneeded ;, option to convert all "if (foo) stmt;" to "if (foo) { stmt; }", etc.) Note that after applying ANY of these changes, the code effect should be EXACTLY the same. This is an important detail to consider when implementing ; addition/removal.
  • Code warnings like Eclipse and NetBeans and auto-fix.
  • Option to auto-remove whitespaces at end of lines

1: Obviously planned.
2: Define "fix"
3: In consideration for later.
4: Will require clarification/investigation. The LGM code editor already has Ctrl+Space which looks for function names matching the typed text or abbreviated by it (e.g. sm<ctrl+space> suggests show_message)
5: Will consider for later.
6: Obviously planned.
7: Will consider for later.
8: In consideration for later. Will mostly be the job of ENIGMA, I believe.
9: In consideration for later.
10: Good idea.

At this point, can we just have an external code editor option?  Geany has all of these and it would be nice to have them before they're actually implemented.
Already an option. Preferences property "externalScriptEditorCommand" in LateralGM. By default, it's set to NULL indicating 'use internal'. Can be overridden by Java preferences (I posted a tutorial on how to do that manually somewhere. Not sure where now, though.)

Proposals / Re: Script Editor Features
« on: February 20, 2011, 02:11:58 am »
1) Line numbering very easy to turn off. Will certainly be an option. Syntax colors will be customizable.
2) This is a LGM feature request, and is not relevant to the code editor. Fairly easy to implement regardless of how the editor is coded.
3) I think we'll be sure to highlight matching brackets at the least. Your suggestion will be considered.
4) Inserting snippets is mostly an LGM feature request, as is adjusting the caret to the first auto-caret. However, dealing with the next auto-caret points may be tricky. Namely, whatever symbol you use would need to either be left in, or removed and remembered somehow.
5) Help stuff won't be implemented until near completion, but your suggestion will be considered.
6) Probably already in the works.
7) Hmm... Might be possible.
8) Interesting one. I believe this would mostly be an LGM feature request.

General ENIGMA / Re: Hey
« on: February 16, 2011, 12:18:26 am »

General ENIGMA / Re: Hey
« on: February 13, 2011, 11:00:00 pm »
Get on the IRC chat.  :eng101:

Announcements / Re: Happenings
« on: February 01, 2011, 06:02:45 pm »
They're very similar. One of the major differences you'll run into is the namespace and the full object-orientedness.
This looks like it might be useful:
The biggest trick behind java is just to know how to use the JavaDocs, because a Java developer accesses them 500x a day.

Announcements / Re: Happenings
« on: February 01, 2011, 12:11:08 pm »

Proposals / Re: LateralGM extensions; official proposal
« on: January 31, 2011, 03:01:22 pm »
Code: (Java) [Select]
//P is the properties, essentially solving the data tier. Resource is the Logic tier.
public abstract class Resource<R extends Resource<R,P>, P extends Enum<P>> implements
 public abstract R makeInstance(ResourceReference<R> ref);
 protected abstract PropertyMap<P> makePropertyMap();
 public abstract Kind getKind();
 public BufferedImage getDisplayImage() { return null; }

//Presentation tier. Becomes visible immediately after instantiation
public abstract class ResourceFrame<R extends Resource<R,P>, P extends Enum<P>> extends MDIFrame {}

Add another abstract class for saving and loading?

This is basically the way LGM is already set up, except that we currently handle all saving/loading in two classes, GmFileWriter and GmFileReader. This means that we'll simply need to split up the file reading/writing into individual resource saving/loading.

Proposals / Re: LateralGM extensions; official proposal
« on: January 31, 2011, 12:32:25 am »
luiscubal: That's exactly what I don't want, because it immediately lumps everything together without separating the 3-tier architecture.

Proposals / Re: ENIGMA Game Format
« on: January 30, 2011, 12:20:06 am »
I like it. I think we'll come to an agreement that will make us both happy.

Proposals / Re: LateralGM extensions; official proposal
« on: January 30, 2011, 12:15:29 am »

Not that I care, but if I have to dissect it, let's start with this:

"The display is just an output, as saving is. The logic tier would simply provide an accessor for standardized access and, at your option, for writing."

Here you compare display to saving, and then mention the logic tier.

"GUI and a save file are no different"
Again comparing GUI to saving. You're making it sound like the presentation tier, but you keep making it sound like it's logic tier.
"I fail to see how the logic tier doesn't encompass the read and write functions"

But again, it doesn't matter whether it's logic or presentation. I was just trying to convey that it's rather large and self-functional, so it probably shouldn't just be dumped in with the other functions.