uceditor-development — Development Mailing List

[Uceditor-development] UnrealScript outline parser working

[Iain M. <iai...@ds...>]

Hi Thomas,

I've managed to create an outline parser for UnrealScript, that parses 
the essential details for UC files, such as declared functions, etc. Now 
that this works, the next step is to integrate this into UCEditor so 
that we can walk the entire class tree of UT2004 and parse all the 
files, storing the essential details. My current thoughts are to use an 
embedded Java database to store the information, so that when we perform 
code completion we can do SQL queries to find potential matches.

Iain

Re: [Uceditor-development] (no subject)

[Thomas M. <to...@me...>]

Hi Iain
Sure, go ahead. I'm not familiar with those generators and to be honest 
I have only heard of Antlr so far as we use it in my company. So I can't 
tell you much about it.

However please keep in mind that for this we need a solid design of the 
core classes (i.e. those classes that are getting generated).
For this I strongly recommend using interfaces. Have a look at the 
uceditor1 classes, in the UCDT package. I planned this initially as a 
base for the generated classes and I presume much of it would still be 
very useful. It's a very basic structure and based on the eclipse core 
classes and interfaces.
It's good to get a certain level of abstraction, to give us some 
flexibility (imagine we find out that the generator isn't usable and we 
have to switch to a different one).

But go ahead with it, would be nice to get this finally implemented :)

Cheers
Tom

iai...@ds... wrote:

>Hi Thomas,
>
>I was bored last night and fancied doing something a bit different, so I wrote a
>SableCC grammar for UnrealScript based on the EBNF that's on UnrealWiki. I
>haven't tested it on any real UnrealScript files yet, but SableCC seems happy
>enough. Perhaps while you're away on holiday I work on a back-end for the
>compiler to generate the class tree and for class overviews.
>
>The grammar is checked into CVS, SableCC can generate the parser source however
>I didn't check that in for now as i might make some changes to it (mainly
>grammar rule names) before I check in the source and start using it to write the
>back-ends we need for UCEditor.
>
>  
>

[Uceditor-development] (no subject)

[<iai...@ds...>]

Hi Thomas,

I was bored last night and fancied doing something a bit different, so I wrote a
SableCC grammar for UnrealScript based on the EBNF that's on UnrealWiki. I
haven't tested it on any real UnrealScript files yet, but SableCC seems happy
enough. Perhaps while you're away on holiday I work on a back-end for the
compiler to generate the class tree and for class overviews.

The grammar is checked into CVS, SableCC can generate the parser source however
I didn't check that in for now as i might make some changes to it (mainly
grammar rule names) before I check in the source and start using it to write the
back-ends we need for UCEditor.

Iain

[Uceditor-development] Unreal Perspective

[Thomas M. <to...@me...>]

Good news
The Unreal perspective is ready now as well! Very easy task!

Tom

Re: [Uceditor-development] Quick status update

[Thomas M. <to...@me...>]

Thanks for your update Iain, I looked at what you've checked in and it 
looks pretty decent so far.

I'll be on holidays for about 10 days, starting on next friday, after 
that I have half a week of holidays here at home, so I'll be able to 
push forward on the remaining stuff.

I'll talk to Jason first to find out if he still wants to stay in the 
team and work on the parser.

Here are the things that I think are necessary for this release:
- Review plugin preferences to see if anything else needs to go in
- Add creation (copying) of the ant build file to the project wizard 
(ant file must be created when project is created)
- Launcher review if anything is missing and if it's usable so far (I 
haven't checked this yet)
- Basic cheat sheet
- Basic perspective (if it's easy to make one)
- all the stuff that you mentioned below, marked for this release

I also would like to try out the update mechanism of eclipse to make 
installation and update easier for our users.

I won't have much time next week so because of my holidays I would like 
to set the release date for saturday31st july. What do you think?

Tom


Iain McGinniss wrote:

> Hi,
>
> It took me a few more days than planned but the project wizard is 
> pretty much complete. There are a few remaining bits that I'd like to 
> sort out, such as the creation of package directories in the project 
> (at the moment I just create the directories manually, however I think 
> I should probably modularize this and update the "Create Package" 
> wizard to use the same code for consistency).
>
> I think the features I'd quite like to see next are:
>
> FOR THIS RELEASE:
> 1. Additional improvements to the UnrealScript editor. Visually 
> displaying matched brackets, highlighting the current line etc will 
> make the editor increasingly intuitive and productive for programmers.
> 2. Improve the launcher to load a specific mod, now that we have 
> settled on the UT2K4 self contained modification style of development.
> 3. Improve the "Create Project" wizard, to set up more of the basic 
> files etc that are required for self contained modifications.
>
> FOR FUTURE RELEASES:
> 1. A UCEditor perspective. We don't have a lot to put in it at the 
> moment, however the first thing I would probably do is to display the 
> packages differently (similar to packages being displayed in the Java 
> perspective). However I agree that this is minor given our current 
> state, although user interface cleanups such as this will definitely 
> improve the product a great deal.
> 2. If Jason has disappeared, I will take over his role in developing a 
> parser for UnrealScript and the associated back-end plugins for 
> generating a code outline, constructing a database of the class 
> hierarchy for code completion, and so on. Perhaps even a lint checker. 
> I have modified a compiler in the past at university so I understand 
> abstract syntax trees etc.
> 3. Code completion is a must. However this, to a large extent, relies 
> upon the parser.
>
> I'll add these to the feature list in sourceforge. When will we be 
> making our first release? I think we should aim for friday next week.
> Iain

Re: [Uceditor-development] Quick status update

[Iain M. <iai...@ds...>]

Hi,

It took me a few more days than planned but the project wizard is pretty 
much complete. There are a few remaining bits that I'd like to sort out, 
such as the creation of package directories in the project (at the 
moment I just create the directories manually, however I think I should 
probably modularize this and update the "Create Package" wizard to use 
the same code for consistency).

I think the features I'd quite like to see next are:

FOR THIS RELEASE:
1. Additional improvements to the UnrealScript editor. Visually 
displaying matched brackets, highlighting the current line etc will make 
the editor increasingly intuitive and productive for programmers.
2. Improve the launcher to load a specific mod, now that we have settled 
on the UT2K4 self contained modification style of development.
3. Improve the "Create Project" wizard, to set up more of the basic 
files etc that are required for self contained modifications.

FOR FUTURE RELEASES:
1. A UCEditor perspective. We don't have a lot to put in it at the 
moment, however the first thing I would probably do is to display the 
packages differently (similar to packages being displayed in the Java 
perspective). However I agree that this is minor given our current 
state, although user interface cleanups such as this will definitely 
improve the product a great deal.
2. If Jason has disappeared, I will take over his role in developing a 
parser for UnrealScript and the associated back-end plugins for 
generating a code outline, constructing a database of the class 
hierarchy for code completion, and so on. Perhaps even a lint checker. I 
have modified a compiler in the past at university so I understand 
abstract syntax trees etc.
3. Code completion is a must. However this, to a large extent, relies 
upon the parser.

I'll add these to the feature list in sourceforge. When will we be 
making our first release? I think we should aim for friday next week.
Iain

Thomas Meier wrote:

> Hi!
> Just to let yo know what I've done so far:
> The builder seems to be working now, although there are some limitations.
>
> The builder is just an Ant builder launch configuration which is 
> effectively the same as adding an Ant builder manually to the project 
> (right click on project, select project properties and select 
> 'builders'). This way the ant launcher configuration can be manually 
> edited later - it's all provided by eclipse.
>
> There are just some small minor edges there at the moment: the ant 
> properties ut.home and project.home are assigned at project creation 
> time and persisted in the launcher configuration file. If you want to 
> use a different ant script, or different ut home directory, you would 
> have to edit the launcher configuration in the project properties. Not 
> very user friendly. I'll fix that later on so that the ant properties 
> are passed to ant at run time.
>
> But it's looking good so far! It's really comfortable now that we can 
> use the eclipse integrated ant builder. So we don't need the UCBuilder 
> anymore!
>
> Next down the list for me is the debugger.
>
> Once we're finished with the main tasks we can polish up by 
> implementing the remaining bits and pieces to make it more user 
> friendly. But I feel we're getting closer now!
>
> Tom
>
> ps: Jason seems to have disappeared from the team, I'll contact him 
> the next days to find out what the story is
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital 
> self defense, top technical experts, no vendor pitches, unmatched 
> networking opportunities. Visit www.blackhat.com
> _______________________________________________
> Uceditor-development mailing list
> Uce...@li...
> https://lists.sourceforge.net/lists/listinfo/uceditor-development
>

[Uceditor-development] Quick status update

[Thomas M. <to...@me...>]

Hi!
Just to let yo know what I've done so far:
The builder seems to be working now, although there are some limitations.

The builder is just an Ant builder launch configuration which is 
effectively the same as adding an Ant builder manually to the project 
(right click on project, select project properties and select 
'builders'). This way the ant launcher configuration can be manually 
edited later - it's all provided by eclipse.

There are just some small minor edges there at the moment: the ant 
properties ut.home and project.home are assigned at project creation 
time and persisted in the launcher configuration file. If you want to 
use a different ant script, or different ut home directory, you would 
have to edit the launcher configuration in the project properties. Not 
very user friendly. I'll fix that later on so that the ant properties 
are passed to ant at run time.

But it's looking good so far! It's really comfortable now that we can 
use the eclipse integrated ant builder. So we don't need the UCBuilder 
anymore!

Next down the list for me is the debugger.

Once we're finished with the main tasks we can polish up by implementing 
the remaining bits and pieces to make it more user friendly. But I feel 
we're getting closer now!

Tom

ps: Jason seems to have disappeared from the team, I'll contact him the 
next days to find out what the story is

Re: [Uceditor-development] Project and packages concept + project docs

[Thomas M. <to...@me...>]

Sounds good to me! I'd say lets do it this way then.
The build files should be called 'build.xml' for mods using the -mod 
switch and build-classic.xml for classic mods. Even though a project 
uses only one build file it's important to have different names. The 
build file should be created in the project directory.
What do you think?

I'm working on creating a default build.xml at the moment, should be 
finished by tomorrow.

We should probably sit down in the next days and make a list of 
outstanding features and other non-functional requirements needed for 
the first release of UCEditor2.0 (e.g. cheat sheets, documentation + 
help, internationalisation etc.)

Tom

Iain McGinniss wrote:

> This sounds reasonable, and is similar to what I had started work on 
> yesterday before you clarified that UCEditor should primarily support 
> UT2K4 and that support for the other games was of a low priority. 
> Doing this the way you suggest before means that it makes creating a 
> classic project slightly easier than if we avoided support for it 
> altogether, which I think is a good idea. My thoughts on how the 
> "create project" wizard should behave are as follows:
>
> PAGE 1
>
> Contents:
> Text field for project name
> Checkbox for whether this is a self-contained modification (i.e. it 
> will be using the -MOD flag).
>
> The user enters the name of the project here, and selects the game 
> installation path that this modification is for. Since we know what 
> type of game this game installation is (as they will have entered it 
> earlier when setting up the game installation paths), we will know 
> whether or not this game supports the -MOD flag. If it does, then we 
> enable the checkbox for a self-contained modification, and have it 
> ticked by default. The user can untick it if they like. If the game 
> does not support the -MOD flag, we disable the checkbox control and 
> untick it. When the checkbox is unticked, we display a warning in the 
> header of the wizard stating that modifications made without using the 
> -MOD flag within UCEditor are not directly supported, and that other 
> plugins (such as CVS) will not operate correctly.
>
> PAGE 2
>
> Contents:
> Check box for creating standard modification directories
> List component for adding 1 or more packages to the project.
>
> The user selects whether or not they want the standard directories 
> created for them (ticked by default). They can then create one or more 
> packages for the modification. The packages will be created in the 
> appropriate location depending on whether this is a self-contained 
> modification or a classic modification. The order of the packages in 
> the list is also the order in which they will be built, as it is 
> important that the build order be correct. What this is essentially 
> doing is indicating implicit dependencies between the packages. A more 
> elegant way of doing this would be perhaps to have a third page on the 
> wizard where the user selects the build order by manually constructing 
> "depends upon" tuples in a table, from which we could construct a 
> directed acyclic graph and create a topological ordering for 
> compilation order. This, in fact, would be a good stand-alone feature 
> for the project properties page as these dependencies would most 
> likely evolve throughout the lifetime of the project. However, for now 
> simply ordering the package list will prove sufficient I feel.
>
> The user, once creating at least one package, can then click "Finish" 
> and the project will be constructed.
>
>
> The appropriate build file for the project will be constructed without 
> use interaction - they do not need to select which type they want. I 
> see your point that it might be useful to allow classic projects to 
> create the build file for a self-contained modification, should it be 
> migrated in the future, however I don't think we can really speculate 
> on the requirements for such an action until we are really concerned 
> with implementing it. So, for now, I think we can omit that step in 
> creating the project.

Re: [Uceditor-development] Project and packages concept + project docs

[Iain M. <iai...@ds...>]

This sounds reasonable, and is similar to what I had started work on 
yesterday before you clarified that UCEditor should primarily support 
UT2K4 and that support for the other games was of a low priority. Doing 
this the way you suggest before means that it makes creating a classic 
project slightly easier than if we avoided support for it altogether, 
which I think is a good idea. My thoughts on how the "create project" 
wizard should behave are as follows:

PAGE 1

Contents:
Text field for project name
Checkbox for whether this is a self-contained modification (i.e. it will 
be using the -MOD flag).

The user enters the name of the project here, and selects the game 
installation path that this modification is for. Since we know what type 
of game this game installation is (as they will have entered it earlier 
when setting up the game installation paths), we will know whether or 
not this game supports the -MOD flag. If it does, then we enable the 
checkbox for a self-contained modification, and have it ticked by 
default. The user can untick it if they like. If the game does not 
support the -MOD flag, we disable the checkbox control and untick it. 
When the checkbox is unticked, we display a warning in the header of the 
wizard stating that modifications made without using the -MOD flag 
within UCEditor are not directly supported, and that other plugins (such 
as CVS) will not operate correctly.

PAGE 2

Contents:
Check box for creating standard modification directories
List component for adding 1 or more packages to the project.

The user selects whether or not they want the standard directories 
created for them (ticked by default). They can then create one or more 
packages for the modification. The packages will be created in the 
appropriate location depending on whether this is a self-contained 
modification or a classic modification. The order of the packages in the 
list is also the order in which they will be built, as it is important 
that the build order be correct. What this is essentially doing is 
indicating implicit dependencies between the packages. A more elegant 
way of doing this would be perhaps to have a third page on the wizard 
where the user selects the build order by manually constructing "depends 
upon" tuples in a table, from which we could construct a directed 
acyclic graph and create a topological ordering for compilation order. 
This, in fact, would be a good stand-alone feature for the project 
properties page as these dependencies would most likely evolve 
throughout the lifetime of the project. However, for now simply ordering 
the package list will prove sufficient I feel.

The user, once creating at least one package, can then click "Finish" 
and the project will be constructed.


The appropriate build file for the project will be constructed without 
use interaction - they do not need to select which type they want. I see 
your point that it might be useful to allow classic projects to create 
the build file for a self-contained modification, should it be migrated 
in the future, however I don't think we can really speculate on the 
requirements for such an action until we are really concerned with 
implementing it. So, for now, I think we can omit that step in creating 
the project.

How does this sound?
Iain

Thomas Meier wrote:

> Hm, you're right that if we only support -mod switch in the dialogs 
> and wizards we might alienate the classic mod community. So what do 
> you think of this:
>
> First of all in the new project wizard we need to offer the user the 
> choice to choose whether default directories should be created for the 
> -mod switch. Classic users can choose to not create those directories. 
> Next steps in the wizard is the creation of the ant build file. To 
> prevent confusion we could offer the creation of 2 build files: 
> build.xml for the -mod build and build-classic.xml for classic mods. 
> The user can choose either one of them or both. This is only for the 
> creation of the build file(s). The user then has to select which build 
> file should be used for the project. He can choose either one of 
> those, or any other build file on the file system.
>
> This seems to be all pretty straightforward from my point of view, and 
> not too confusing. For UT2k4 the defaults should be all set up to 
> support the -mod switch, so that by default the option to create all 
> directories is selected, and only the option for the creation of the 
> -mod build.xml file is selected. For UT or UT2k3 the defaults should 
> be that no directories are created and both build files (the -mod 
> build file as well, just to support later migration of the project if 
> we ever plan something like that)
>
> However when it comes to the launcher we could just display the 
> command line thats being used for launching and an option whether to 
> use the default command line (which is aimed towards the -mod command) 
> or whether to let the user modify it. If the user disables the option 
> to use the default, he can edit the command line. He can enter 
> whatever he likes and it's up to him to enter a valid command line. We 
> could provide support with a cheat sheet to make it easier.
>
> What do you think of this? Don't treat this concept as written in 
> stone, it's just my opinion and open for discussion :)

Re: [Uceditor-development] Project and packages concept + project docs

[Thomas M. <to...@me...>]

Hm, you're right that if we only support -mod switch in the dialogs and 
wizards we might alienate the classic mod community. So what do you 
think of this:

First of all in the new project wizard we need to offer the user the 
choice to choose whether default directories should be created for the 
-mod switch. Classic users can choose to not create those directories. 
Next steps in the wizard is the creation of the ant build file. To 
prevent confusion we could offer the creation of 2 build files: 
build.xml for the -mod build and build-classic.xml for classic mods. The 
user can choose either one of them or both. This is only for the 
creation of the build file(s). The user then has to select which build 
file should be used for the project. He can choose either one of those, 
or any other build file on the file system.

This seems to be all pretty straightforward from my point of view, and 
not too confusing. For UT2k4 the defaults should be all set up to 
support the -mod switch, so that by default the option to create all 
directories is selected, and only the option for the creation of the 
-mod build.xml file is selected. For UT or UT2k3 the defaults should be 
that no directories are created and both build files (the -mod build 
file as well, just to support later migration of the project if we ever 
plan something like that)

However when it comes to the launcher we could just display the command 
line thats being used for launching and an option whether to use the 
default command line (which is aimed towards the -mod command) or 
whether to let the user modify it. If the user disables the option to 
use the default, he can edit the command line. He can enter whatever he 
likes and it's up to him to enter a valid command line. We could provide 
support with a cheat sheet to make it easier.

What do you think of this? Don't treat this concept as written in stone, 
it's just my opinion and open for discussion :)

Iain McGinniss wrote:

> Yes, this is fine, however it does mean that we are only directly 
> supporting UT2004 (and later games which support the -mod flag) within 
> UCEditor. This isn't necessarily a bad thing, we will only be 
> alienating a very small fraction of the current Unreal development 
> community. I will make sure the wizards are geared solely towards 
> UT2004 in future.
>
> Iain

Re: [Uceditor-development] Project and packages concept + project docs

[Iain M. <iai...@ds...>]

Yes, this is fine, however it does mean that we are only directly 
supporting UT2004 (and later games which support the -mod flag) within 
UCEditor. This isn't necessarily a bad thing, we will only be alienating 
a very small fraction of the current Unreal development community. I 
will make sure the wizards are geared solely towards UT2004 in future.

Iain

Thomas Meier wrote:

>Hi Iain!
>
>I probably didn't make this point very clear in the documentation. I was
>thinking of not supporting the classic way in the wizards at all. If we
>would offer the user two ways of creating a project we would have two
>different concepts for projects. It is possible to do this, but from my
>experience such things cause a lot of trouble. It also seems that classic
>mods don't really fit into the eclipse concept (as you mentioned before,
>cvs for linked resources is not supported etc).
>
>Therefore I suggest that users can only create projects using the -mod
>switch. But it's still technically possible for users to use a project
>created in uceditor the classic way. They just have to follow the steps
>outlined in the document.
>
>For us this means we develop the UCEditor entirely for the -mod switch,
>but keep an eye on classic mods.
>
>What do you think? Does this make sense?
>  
>

Re: [Uceditor-development] Project and packages concept + project docs

[Thomas M. <to...@je...>]

Hi Iain!

I probably didn't make this point very clear in the documentation. I was
thinking of not supporting the classic way in the wizards at all. If we
would offer the user two ways of creating a project we would have two
different concepts for projects. It is possible to do this, but from my
experience such things cause a lot of trouble. It also seems that classic
mods don't really fit into the eclipse concept (as you mentioned before,
cvs for linked resources is not supported etc).

Therefore I suggest that users can only create projects using the -mod
switch. But it's still technically possible for users to use a project
created in uceditor the classic way. They just have to follow the steps
outlined in the document.

For us this means we develop the UCEditor entirely for the -mod switch,
but keep an eye on classic mods.

What do you think? Does this make sense?

> The documentation looks very good to me, it matched my expectations of
> how I expected UCEditor to work quite nicely. The only awkward issue is
> that of "classic" UT mods - while it is possible for us to support this
> using symbolic links, the behaviour of the wizards when creating such a
> project will be different. The project will be created in the workspace
> rather than under the installation directory of a particular game. I
> think this should be relatively easy to handle however, we can just have
> two different wizards, one for creating a self-contained mod (using the
> -mod switch), and one for creating a classic mod.
>
>  From the code we have at the moment it should be trivial to modify it
> to support the -mod option. I will also modify the Create Package wizard
> so that it behaves differently depending on whether the project is a
> -MOD project or a classic project. Within a -MOD project the package
> will be placed directly within the project's directory, while in a
> classic mod it will place it within the game installation directory and
> create a symbolic link to the folder. This should make it fairly
> transparent to the user, so they do not need to learn two different
> modes of interaction depending on which type of mod they are writing.
>
> Still, I agree that we should be promoting the use of -MOD for UT2K4
> projects. For the other games which do not support this flag, we will
> only allow the creation of classic projects.

Re: [Uceditor-development] Project and packages concept + project docs

[Iain M. <iai...@ds...>]

The documentation looks very good to me, it matched my expectations of 
how I expected UCEditor to work quite nicely. The only awkward issue is 
that of "classic" UT mods - while it is possible for us to support this 
using symbolic links, the behaviour of the wizards when creating such a 
project will be different. The project will be created in the workspace 
rather than under the installation directory of a particular game. I 
think this should be relatively easy to handle however, we can just have 
two different wizards, one for creating a self-contained mod (using the 
-mod switch), and one for creating a classic mod.

 From the code we have at the moment it should be trivial to modify it 
to support the -mod option. I will also modify the Create Package wizard 
so that it behaves differently depending on whether the project is a 
-MOD project or a classic project. Within a -MOD project the package 
will be placed directly within the project's directory, while in a 
classic mod it will place it within the game installation directory and 
create a symbolic link to the folder. This should make it fairly 
transparent to the user, so they do not need to learn two different 
modes of interaction depending on which type of mod they are writing.

Still, I agree that we should be promoting the use of -MOD for UT2K4 
projects. For the other games which do not support this flag, we will 
only allow the creation of classic projects.

Iain

Thomas Meier wrote:

> Hi!
>
> I was thinking about the way we organise the project and packages and 
> came up with a solution. It's mainly what you mentioned, by using the 
> -mod command line switch.
> I've put everything into a HTML document and added it to CVS. It's in 
> the internal_doc directory just under the uceditor directory. Let me 
> know what you think!
>
> If you have any comments, lets discuss them here. We can make 
> modifications to the document when we all approve of them.
>
> I'll also make some paper prototypes of the mentioned areas so that we 
> have a base for discussions.
>
> PS: I changed the mailing list so that the reply-to goes to the list.
>
> Tom

[Uceditor-development] Project and packages concept + project docs

[Thomas M. <to...@me...>]

Hi!

I was thinking about the way we organise the project and packages and 
came up with a solution. It's mainly what you mentioned, by using the 
-mod command line switch.
I've put everything into a HTML document and added it to CVS. It's in 
the internal_doc directory just under the uceditor directory. Let me 
know what you think!

If you have any comments, lets discuss them here. We can make 
modifications to the document when we all approve of them.

I'll also make some paper prototypes of the mentioned areas so that we 
have a base for discussions.

PS: I changed the mailing list so that the reply-to goes to the list.

Tom

Re: [Uceditor-development] Work done last night refactored and extended

[Thomas M. <to...@me...>]

Sounds good! I just checked and it looks very good so far.

I also checked if it's possible in eclipse to share out linked folders 
to cvs. But it doesn't work. When creating a linked folder, the next 
synchronise with the repository will ignore it. Since sharing out to cvs 
is a basic operation, we probably can't use linked folders. Probably 
with hacks, but I don't see a clean solution at the moment.

Looks like we have to go with your suggestion of using the -mod 
parameter and creating a mod directory, and I have to buy a copy of UT2k4

Tom

Iain McGinniss wrote:

> Hi guys,
>
> I refactored all the code I wrote last night to make it much tidier 
> than it was, splitting it into multiple classes and using a sensible 
> class hierarchy etc. The feel of the editor is becoming quite similar 
> to that of the Java editor, except of course it does not support code 
> completion yet. I've added a few extra features on top of what I had 
> last night, so the list of things the editor can do is now:
>
> 1. If you were to type:
>    if (
>    the editor will insert the close bracket for you and position the 
> cursor between the brackets.
>
> 2. If you had text as follows, and the caret is at the position marked X:
>    if((a * b) + (c * d) == 3 X)
>    and you type a closing round bracket, this will be ignored and the 
> caret placed as follows:
>    if((a * b) + (c * d) == 3 )X
>    This is to allow  you to type in the usual flowing way without the 
> additional brackets that the editor inserts for you getting in the way.
>
> 3. The editor behaves similarly for square brackets and quotes (i.e. 
> when creating strings) for array subscripts as 1 and 2 above.
>
> 4. The editor will complete multi-line comments for you. If you were 
> to enter the following:
>    /*
>    Then hit the return key, the result is as follows (with the X 
> marking the caret position):
>    /*
>     * X
>     */
>
> 5. When pressing the enter key within a multi line comment, the editor 
> will insert a * character on the next line and indent it to the 
> correct position.
>
> 6. If you were to type
>      if(aTest) {
>      the editor will complete the code block for you as follows:
>      if(aTest) {
>    }
>
> 7. At any position at which press the return key, the caret will 
> appear at the correct indentation level on the next line.
>
>
> As you can see, this behaviour is quite similar to many of the common 
> behaviours in the Java editor, and it seems to work quite nicely at 
> the moment. If the document is not syntactically valid (especially if 
> there are mismatched braces, brackets and so on) then the behaviour of 
> the editor will be unpredictable, however there isn't a great deal I 
> can do about this at the moment. The Java editor behaves equally badly 
> if you have a syntactically incorrect document so I think it would be 
> unreasonable to expect the unrealscript editor to do any better :)
>
>
> I think I've done enough for today, off to play some games :)
> Iain
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital 
> self defense, top technical experts, no vendor pitches, unmatched 
> networking opportunities. Visit www.blackhat.com
> _______________________________________________
> Uceditor-development mailing list
> Uce...@li...
> https://lists.sourceforge.net/lists/listinfo/uceditor-development
>
>

[Uceditor-development] Work done last night refactored and extended

[Iain M. <iai...@ds...>]

Hi guys,

I refactored all the code I wrote last night to make it much tidier than 
it was, splitting it into multiple classes and using a sensible class 
hierarchy etc. The feel of the editor is becoming quite similar to that 
of the Java editor, except of course it does not support code completion 
yet. I've added a few extra features on top of what I had last night, so 
the list of things the editor can do is now:

1. If you were to type:
    if (
    the editor will insert the close bracket for you and position the 
cursor between the brackets.

2. If you had text as follows, and the caret is at the position marked X:
    if((a * b) + (c * d) == 3 X)
    and you type a closing round bracket, this will be ignored and the 
caret placed as follows:
    if((a * b) + (c * d) == 3 )X
    This is to allow  you to type in the usual flowing way without the 
additional brackets that the editor inserts for you getting in the way.

3. The editor behaves similarly for square brackets and quotes (i.e. 
when creating strings) for array subscripts as 1 and 2 above.

4. The editor will complete multi-line comments for you. If you were to 
enter the following:
    /*
    Then hit the return key, the result is as follows (with the X 
marking the caret position):
    /*
     * X
     */

5. When pressing the enter key within a multi line comment, the editor 
will insert a * character on the next line and indent it to the correct 
position.

6. If you were to type
   
    if(aTest) {
   
    the editor will complete the code block for you as follows:
   
    if(aTest) {
    }

7. At any position at which press the return key, the caret will appear 
at the correct indentation level on the next line.


As you can see, this behaviour is quite similar to many of the common 
behaviours in the Java editor, and it seems to work quite nicely at the 
moment. If the document is not syntactically valid (especially if there 
are mismatched braces, brackets and so on) then the behaviour of the 
editor will be unpredictable, however there isn't a great deal I can do 
about this at the moment. The Java editor behaves equally badly if you 
have a syntactically incorrect document so I think it would be 
unreasonable to expect the unrealscript editor to do any better :)


I think I've done enough for today, off to play some games :)
Iain

[Uceditor-development] Basic indentation control added to UnrealScript editor

[Iain M. <iai...@ds...>]

Hi guys,

Just a quick status update to let you know I have commited some 
additions to the UnrealScript editor to add support for basic 
auto-indentation and bracket closing. I'll be doing what I can with the 
editor over the next couple of days until we can come to some decision 
as to how to implement projects.

Iain

Re: [Uceditor-development] Multiple packages per project - a happy medium

[Thomas M. <to...@me...>]

That sounds pretty good - I haven't heard of that myself!

I have a look at this in more detail tomorrow. Maybe we could go for 
this as the primary solution but also allow adding packages 'the old 
way' by symbol links. The central thing for this is that the ini file is 
stored in a project directory, so it works for both solutions (the new 
ut2k4 one and the symbolic link one)
I'll investigate this further tomorrow.
(Damn now I have to buy ut2k4 for this - I'm not even playing Unreal 
games anymore ;) )

Tom

Iain McGinniss wrote:

> Hi guys,
>
> I think i might have found a nice way to allow our projects to support 
> multiple packages without any of the potential problems which I 
> identified previously. Unfortunately this method is only supported in 
> UT2K4, so you might not like the idea of making UCEditor only support 
> UT2K4 and later games.
>
> The reference for this solution can be found here:
> http://unreal.epicgames.com/ut2004/tutorials/modsupport.htm
>
> Essentially, UT2K4 allows you to completely self-contain your 
> modification in a single directory. This directory can contain as many 
> packages as you like, and I think this is a much neater way of doing 
> things. If our UCEditor projects were to use this method, it would 
> mean the packages can all be contained within the project directory, 
> and the project directory contained within the game installation as I 
> have it at the moment. As I mentioned before, this is not supported in 
> previous games and so we'd be limiting what you can do with UCEditor 
> to a fair extent. However, given our target users, most have probably 
> migrated to UT2K4 or are in the process of doing so. As such, we will 
> only be alienating a very small portion of the development community, 
> and it might not be worth the large amount of extra hours that will be 
> required to create a more complex solution.
>
> Iain

[Uceditor-development] Reply-to address

[Iain M. <iai...@ds...>]

Hi Thomas,

As Jason mentioned earlier, it is quite irritating that the reply-to 
address for emails sent out for this list are not back to the list but 
to the individual in question. If it is possible to configure this on 
the list, could you set it so that the reply-to is to the list? I don't 
know how many times I've made the mistake of only replying to the sender 
now, and it's becoming annoying :)

Iain

Re: [Uceditor-development] JDT dependencies

[Iain M. <iai...@ds...>]

I read through the post, it's interesting to see that some developers do

in fact split their mod into different packages. I thought this would 
become incredibly messy, especially given the flat hierarchy for 
packages. Their development UT2004 directories must be stuffed with 
directories :)

I think the first method you mention below is probably better, however I 
have no idea how you would actually go about implementing this. Is the 
idea to have all the packages stored within a project directory in the 
eclipse workspace directory, and then copy all the files over to the 
game installation directory when the game is being built and/or run? Or 
to only contain our UCEditor specific files in the project folder, and 
have symbolic links to the associated package directories where all the 
code etc is contained for the project? The first option seems a bit 
messy, and would involve a lot of copying of files. The second option 
therefore seems better, however symbolic links are not as easy and might 
complicate matters when using other plugins. For instance, if you want 
to use the CVS plugin to use source control for your project, having the 
directory structure scattered all over the real hard disk directory 
structure will most likely confuse CVS and stop it working properly. 
That's just a hunch, I might be wrong.

I think there are definitely quite a few things we need to clear up 
about how we want this IDE to work before we should proceed with the 
work on the projects, launchers, builders etc. There isn't a great deal 
I can do with the editor for now until we have a working UnrealScript 
parser. As such I'd like to keep my attention on the launcher and the 
wizards. I will stop work for the time being and write up a small 
document which describes how I would expect the project to work. I'm 
familiar with use cases (though it's been a year since I've used them, 
so I'm rusty) so will to organise into some sort of UML document. I'll 
get to work on that just now, hopefully I'll have something to email by 
tomorrow afternoon.

Iain

Thomas Meier wrote:

> I understand your point and it makes sense that it simplifies the 
> concept of projects/packages. However it seems that there are some 
> mods who do have more than one package. I asked in the BU forums about 
> this, read here: http://forums.beyondunreal.com/showthread.php?t=138884
> Now I don't know if this makes really sense because I'm not that 
> experienced with development of mods. But simply for the fact to 
> support those mods with multiple packages I think we should support them
>
> Instead we could make life for single package mods a bit easier. There 
> are two ways to achieve that:
> 1: in the new project wizard have a page to create the first package. 
> This way when creating a new project you automatically have a default 
> package. But the project directory and package directory are still 
> different.
> 2: give the user the option of creating a single-packaged project in 
> the project wizard. If the user selects this option, the project 
> directory and package directory will be the same. However if we do 
> this, we also need to offer the possibility to change the project to a 
> multiple-package project. If the user chooses to do this, he has to 
> select a new directory for the project. The system then copies all 
> project related files into that directory. But changing the project 
> type is probably rather rarely used.
>
> Personally I think solution #1 is the best because we have the same 
> concept throughout the application: multiple packages. Solution #2 has 
> mixed concepts and probably causes some inconsistencies in the 
> application. From my experience inconsistencies in application causes 
> lots of trouble and usually delay the development if not sorted out early.
>
> What do you think?

[Uceditor-development] Multiple packages per project - a happy medium

[Iain M. <iai...@ds...>]

Hi guys,

I think i might have found a nice way to allow our projects to support 
multiple packages without any of the potential problems which I 
identified previously. Unfortunately this method is only supported in 
UT2K4, so you might not like the idea of making UCEditor only support 
UT2K4 and later games.

The reference for this solution can be found here:
http://unreal.epicgames.com/ut2004/tutorials/modsupport.htm

Essentially, UT2K4 allows you to completely self-contain your 
modification in a single directory. This directory can contain as many 
packages as you like, and I think this is a much neater way of doing 
things. If our UCEditor projects were to use this method, it would mean 
the packages can all be contained within the project directory, and the 
project directory contained within the game installation as I have it at 
the moment. As I mentioned before, this is not supported in previous 
games and so we'd be limiting what you can do with UCEditor to a fair 
extent. However, given our target users, most have probably migrated to 
UT2K4 or are in the process of doing so. As such, we will only be 
alienating a very small portion of the development community, and it 
might not be worth the large amount of extra hours that will be required 
to create a more complex solution.

Iain

[Uceditor-development] Build concept

[Thomas M. <to...@me...>]

Hi guys
Just want to check what you guys think of this. Instead of having an own 
homegrown builder with only limited flexibility we could just use ant 
scripts for the build process. My initial idea was to implement an own 
builder that utilises ant, but why bother when a complete ant builder is 
already existing?
Eclipse already offers an ant builder that you can add to any project. 
Just right-click on any project, select 'properties' and go to the 
builders section. There you can add an ant builder.

So when creating a new project we can create a default ant build file 
and add it programmatically as a builder to the project. From that point 
on if the project is being built, the ant file will be used. If the user 
later wishes to modify the build process, they can simply edit the ant 
file as they please. Furthermore they can use the build file outside 
eclipse. And share it out on cvs.

In the new project wizard we can give the option to automatically create 
a default ant build file and associate it to the project. Otherwise the 
user can do it later manually with their own build file.

The only problem with that is that at the moment there is no clear way 
(but there is a dirty one) to add an ant builder programmatically to a 
project. However the code necessary to do this would be fairly small and 
we could separate that code so that we can adopt it to future versions 
of eclipse.

What's your opinion on this?

Tom

[Uceditor-development] New launcher committed

[Iain M. <iai...@ds...>]

The new game launcher is committed and working (well, I've only tested 
it with UT2K4). It's quite basic and quite different to the original one 
from what I can see. It works as follows:

The launcher is associated with a game installation rather than an 
individual project. I did this for simplicity's sake at the moment. The 
executable for launching the game is determined using the utility 
methods in GameInstallLocation, which in turn accesses the constants in 
GameType which give the paths to the executable, master ini file etc for 
each defined game type. The user is able to define the command line 
options, which would let them set the game to run a mod that rebrands 
the menus and so on.

The reason I chose to do it this way is mainly to keep it simple - as we 
have already been discussing I believe that a project should have a 1 to 
1 mapping with a package under a specific game installation location. As 
such, there is no need to be able to set what packages are being used 
and so on - it is simply a matter of running the correct executable for 
the game. I don't have a great deal of experience with deploying 
modifications for unreal games at the moment, so I don't know what the 
requirements are for a launcher such as this (what settings mod makers 
would like etc). The mod I am making at the moment does not require any 
special settings to run - UT2K4 simply detects it's existence when it 
runs and add's it to the menus for creating games. As such, the launcher 
such as it stands is sufficient for my needs. However, I do realise that 
more sophisticated mods may require more complex settings which we could 
help to configure in the launcher.

One thing I noticed is that it's not actually possible to access the 
"Run..." option from the Resource perspective, which is the default when 
testing the plugin. It is accessible from the Java perspective, however 
obviously we should not be expecting our users to switch to the Java 
perspective in order to configure their run settings. As such, it would 
probably be a good idea for us to set up an UnrealScript perspective and 
set things the way we need them, so the users can access all the 
features we have at the moment (and in the future) easily. I might look 
into this tomorrow night, however I do realise this is quite low 
priority given the countless other things we have to add before UCEditor 
will be worth using.

Thomas - we seem to be stepping on each other's toes slightly in the 
code. I had to resolve some conflicts, which seems to be as a result of 
your checkin for the builder. I'll need to speak to you about what 
you're using in IUCConstants tomorrow I think, as I have removed some 
things which you might be using and I didn't realise.

Iain

Re: [Uceditor-development] JDT dependencies

[Thomas M. <to...@me...>]

I just got your changes from cvs. I see now what you mean with merging 
the project/package wizard. I assume your concept for creating a 
project/package is that both are the same? So a project is directly 
associated with a subdir under a UT installation and contains the 
classes/textures/etc directories. Also the ini file.
The good thing about this concept is that its simple. And easy to 
understand. However you'd be limited to only one package per project. 
I'm not sure of the needs of the mod developers in this case, but isn't 
that good development style to have more than one package, e.g. a 
package containing common classes etc and other packages for other parts 
of the mod?
Do you know how other mod developers organise their code? Do they have 
more that one package?

Re: [Uceditor-development] Status update

[Thomas M. <to...@me...>]

Hi Iain
Yes thats fine, feel free to work on the launcher!
I'm working on the builder at the moment.

About the icon: Yes, you'd use a decorator for this which can be defined 
in the plugin.xml as far as I know. Also have a look at the eclipse 
articles, there is an article about eclipse UI design guidelines which 
might be helpful.. Personally I think the JDT is not the best reference 
for developing plugins because the JDT is very complex. It's better to 
use the eclipse help, eclipse articles from the website and if nothing 
else helps the eclipse discussion forum ;)
However I wouldn't worry to much about this right now ;)

Good luck
Tom

Iain McGinniss wrote:

> Hi guys,
>
> I had modified the "new project" wizard for UCEditor projects so they 
> now support multiple game installations. Now that this is done, I'm 
> going to work on the project runner to run the game from within 
> eclipse. I realise Thomas that I said before that I thought you should 
> do this however I feel like doing it now, and it ties in with my work 
> on supporting multiple game installation locations.
>
> Thomas, do you know how to change the icon for a UCEditor project? 
> Ideally what I'd like to see is the project folder for a UCEditor 
> project having a little U at the top-right, similar to Java projects 
> which have a little J. I had a look around the eclipse documentation 
> and the closest I could come to finding out how to do this was to use 
> a lightweight resource decorator, however I could not find any 
> evidence of this method being used in the JDT source code.
>
> Cheers,
> Iain
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital 
> self defense, top technical experts, no vendor pitches, unmatched 
> networking opportunities. Visit www.blackhat.com
> _______________________________________________
> Uceditor-development mailing list
> Uce...@li...
> https://lists.sourceforge.net/lists/listinfo/uceditor-development
>
>