Messages

The splash screen looks really nice Would it be possible to update the icons of the AGS Editor (taskbar icon and etc.) to match the cup in the splash screen?

I had already done that, the only thing I did was place "selectedAttackButton = control;" into the function for my button. I didn't copy the whole function over since the name is different anyway.

Did you try this?

Code: ags

selectedAttackButton = control.AsButton;

Humm, I don't see why this would have any impact on development?

side note: I tried again my 3.4.0.6 and the brief blinking that used to happen every second when the cursor was not moving (which you don't experience), did not happen today. So maybe there's a second (more rare) issue, but eh, who cares? The annoying one is gone!

I've owned some glitchy mouses over the ages that detected movement when they were standing still. Maybe there was just something with your mouse that detected small movements that were too microscopic to see on the screen with the naked eye. Or maybe it was gremlins.

[EDIT:]

My cursor displays normally when I don't move the mouse, however I can confirm that it does intense flickering when the mouse is moving. Did you try to see if the problem persists on other versions of AGS? I tried as far back as AGS v3.1 and the problem was there as well.

EDIT:
Monsieur OUXX, you're able to compile the AGS source right? Could you try following quick fixes and see if it improves your problem?

AGS v3.3.5
AGS v3.4.6 Alpha

YouTrack does looks a lot more comfortable to use, minus the extra registration issues. My vote is on YouTrack.

The most common in my experience is to let users choose themselves on install between %ALLUSERSPROFILE% and %USERPROFILE%. This is a fairly conventional solution so that's probably the way to go I think.

Spoiler

[close]

Curly brackets is used to include several lines of code, you're code executes anyway because you don't have them. Without them the if and else-if will execute the first line after the condition only.

Code: ags

if(condition)
  DoSomething1(); // This will happen if condition1 is true
else if(condition2)
  DoSomething2(); // This will happen if condition2 is true
  DoSomething3(); // This will happen either way

You want do this

Code: ags

if(condition)
{
  DoSomething1(); // This will happen if condition1 is true
}
else if(condition2)
{
  DoSomething2(); // This will happen if condition2 is true
  DoSomething3(); // This will happen if condition2 is true
}
DoSomething4(); // This will happen either way

EDIT: I didn't notice you made two posts with the exact same question and got your answer already

I agree that this has grown out of proportions, way beyond the scope of the original fix. I'd be happy to just apply what was originally going to be applied if we agree that the design-stuff will be re-visited later, more specifically I will be applying this:

The user adds a new resource.
Scenario 1: It is stored in a subfolder of the game folder -> it is stored as .\sounds\bang.ogg
Scenario 2: It is stored somewhere else -> it is stored as C:\Users\cat\Pictures\logo.bmp

A final question to Crimson Wizard, on GitHub you requested this of me

Another thing, would it be possible to run an automatic fixup for all the existing references when project being opened and apply the relative path rule? This will help when importing existing projects with new Editor.

Should I still look into this? Or is it better to drop it for now?

I like RickJ's choose your own destinypath system, set it in generalsettings somewhere and use your relative or absolute path for this project and set it different for another project. Everything fine, just define the default setting... (btw, I like relative paths)
I don't understand what ChamberOfFear's suggestion offers besides making it more complicated. I don't quite understand it already so this must be really complicated...

Doesn't matter I've already discarded it.

What I thought RickJ is proposing is a kind of global PATH setting which directs to folders containing resources, where the sprites should be searched for. His last comment kinda suggests this.
But I would wait for him to clarify this himself.

In retrospect that makes a lot of sense

So, what I may suggest, is to have a list of only relative paths (either global, or project-specific). If the file was taken from any of those directories (and their subdirectories), then the relative path is stored. Otherwise - absolute path is stored.
The default value for this PATH setting would be ".\", i.e. "project directory".

I think this is the best solution proposed so far however, it's simple and elegant, and has little or zero chance to break previous games. But a couple of details needs to be hammered out.

• Should the list be global, project-specific or both? To me it makes sense for it to be project-specific.
• Where in the editor should the list be accessible for the user?

I'm almost certain I'm the one who has been misunderstanding things, probably got a little too overzealous when I realized it was possible to implement a solution that was satisfactory for both trouble scenarios. So let me try this again.

Every asset (sprites, audio and font) has a "SourceFile"-property which stores the file location for the asset in question, currently it stores absolute paths, always. The proposed fix is to store both absolute and relative path in a single string inside the "SourceFile"-property.

Using this we can find an asset by reading the SourceFile-property as follows

Code: pseudo

if relative_path == valid
  use relative path
else if absolute_path == valid
  use absolute path
else
  could not verify path

Building off RickJ's example the format of the string should be as follows

Code: text

SpritePath=PATH=absolute_path;relative_path;
AudioPath=PATH=absolute_path;relative_path;
FontPath=PATH=absolute_path;relative_path;

Example (The referenced file is inside the game project folder):

Code: text

SpritePath=PATH=C:\MyGame\Assets\Sprites\sprite001.png;Assets\Sprites\sprite001.png;

Example (The referenced file is outside the game project folder, but on the same disk):

Code: text

SpritePath=PATH=C:\Assets\Sprites\sprite001.png;..\Assets\Sprites\sprite001.png;

Example (The referenced file is outside the game project folder, and on a different disk):

Code: text

SpritePath=PATH=D:\Assets\Sprites\sprite001.png;D:\Assets\Sprites\sprite001.png;

E: erm, or we all are confused? maybe we should restate what we have decided again?

I think I was the one that got confused. For safe measure, please restate how the implementation should be.

[If absolute paths is checked:]

Would it be possible to detect if the path is a sub-path of the main game folder and in this case keep it relative? In any other case it could be absolute.

I believe so yes, to be more specific I imagine the end solution something like this.

If absolute paths is checked:

Files and folders outside the project	Absolute paths
Files and folders inside the project	Relative paths

If relative paths is checked:

Files and folders outside the project	Relative paths
Files and folders inside the project	Relative paths

Files and folder located on another disk will always return an absolute path.

I'll take that as we're in agreement then I'll take a look at it

That's a fairly good idea actually, I was worried there was no win-win situation in this. But if we add a new project specific property that lets the game developers choose if the path should be stored as relative or absolute we would meet the needs of both situations and not break previous projects.

About the sprites: I'm not sure how what you're saying relates to the "put sound and sprite files in source control" option.

If you check the option for sound and sprites the Source Control integration will add the files Crimson Wizard mentioned on check-ins. That's what the feature does, it adds "acsprset.spr" and "sprindex.dat".

I'm going to try. However I can't find any tutorial explaining how to hook up any non-MS repository (non-SourceSafe, non-TFS) to MSSCCI. I'd like to start off with a local, lightweight SVN or git server. If anyone has a lead...

I don't think you can, at least that was my conclusion when I was doing experiments on this a year back. The AGS Editor code recognizes Source Control Software with a registry check to a value which is used by Microsoft to store Source Control Providers.

Spoiler

Code: c#

private void GetSourceControlProviderDLL()
{
  RegistryKey key = Registry.LocalMachine.OpenSubKey(@"SOFTWARE\SourceCodeControlProvider");
  if (key != null)
  {
    string providerPath = (string)key.GetValue("ProviderRegKey");
    key.Close();
    if (providerPath != null)
    {
      key = Registry.LocalMachine.OpenSubKey(providerPath);
      if (key != null)
      {
        _providerName = (string)key.GetValue("SCCServerName");
        _providerDLL = (string)key.GetValue("SCCServerPath");
        key.Close();
      }
    }
  }
}

[close]

However if I remember correctly it isn't really an impressive feature, it pretty much just boots up the external software using modified project files as arguments. You're probably better off using independent tools outstide the editor like Crimson Wizard and Khris has already mentioned. Using a fine tool like Git Extensions or TortoiseGit complimented with a good gitignore would give you capabilities identical to the AGS integration, minus the menu-dialogs.

[YES.]

Wasn't/Isn't Visual C# a proprietary piece of software that runs only at a proprietary Operating system?

I feel like this should be be answered once and for all since it keeps popping up in this discussion.

YES. Visual C# IS a proprietary piece of software running only on Windows. However, it isn't relevant for any of the points you're trying to make.
The term "Visual C#" refers to the Visual Studio implementation of C#, which neatly packs compiler, debugging, code editor and a bunch of other tools together. But this does not mean that you are restricted to using Visual Studio, in fact a C# project is interchangable between the following IDEs of the top of my head(with limitations).

• Visual Studio
• MonoDevelop
• SharpDevelop
• Xamarin Studio

Both MonoDevelop and Xamarin Studio runs cross-platform, that is Windows, Linux and OS X. MonoDevelop is even open-source(https://github.com/mono/monodevelop). And thanks to Mono(which has been mentioned several times now) you can also build and run programs developed in C# on other platforms than Windows. http://www.mono-project.com/ Also open-source(https://github.com/mono/mono). Granted, it is true that the AGS Editor cannot compile to non-Windows or be opened in other IDEs, but this is the result of project-specific implementations(i.e. it's not Mono-compatible) and is therefore not a valid argument in the C# vs B4X discussion.

I think a lot of the confusion is caused by the constant use of the term "Visual C#" in the wrong context, people usually say "C# .NET" for Windows programs made with C# and "C# Mono" for cross-platform programs made with C#. Almost every statement in this thread arguing against C# is based on that it doesn't have cross-platform support, which simply isn't true.

I am honestly a little baffled as to why this is not understood or as to why Visual C# is a better alternative to this

Joe, just like CW and Alberth I do not wish to discourage you from this project, but if you're serious about making the editor compatible with multiple platforms I believe you are better of teaching yourself C# and devote your workload into making the already existing code-base Mono-compatible. If you're familiar with C, C++, Java or any programming language with similar syntax it should take only a couple of weeks to get familiar with the language(at least that was my experience). Starting over with a completely new project is a huge project, and your conclusion that B4X is a better option appears to be based on false assumptions on what C# can and cannot do. Based off your own arguments for B4X, C# does everything equal or better.

Could you provide a minimum example of the issue in code?

Exactly why isn't "Vertical Indentation Guides" and "Prettier Folding" implemented? A quick test shows me that cherry picking the commit responsible for those changes from "feature_editor_drac" into "develop-3.3.5" is conflict free. Is there something about the implementation that needs to be improved?