Messages

I think that's a good idea!

It think it's a good idea.
But I for one wouldn't want to maintain such a list and I imagine no one else would, so I think adding each module's "script-o-name" to the list of modules in the wiki would probably be the best solution.

In fact, since in the wiki there's hardly any information on the modules anyway, why not just list them all by their script-o-name where available?
Either that, or adding the script-o-name separately without making it look like a mess.

S/he also posted in the main Tech forum, I think Colxfile has been able to help.

True, important points should probably be emphasized. I'll get on it.

Edit: Done.

My opinion would be to leave it up to the develovers, as long as it relates to module internals.

Any numbers as well as any other names should be ok... provided there is a prefix there. Developer may decide what method to use taking into account the length of module/gui name.

Of course, the developer is free to do as he chooses. Nobody forces him to follow these guidelines.
Remember, they are only suggestions, but they should be consistent in themselves.

Let's leave it at that. I'll change the suggestion to camel notation.

CJ, you might want to take a look at this thread in the Beginners Forum. A user reported a weird crash with v2.72. Maybe you can make sense of it.

You're welcome! Glad you got it working.

I can't see anything wrong with the code you posted.

Are the remove overlay lines the reason for the crash? What happens if you comment them out?

At least in AGS v2.61, "program pointer +379" was related to DirectDraw messing up.
But that doesn't have to mean anything as in newer versions these error codes can be different.

Any chance you could upload the game for us to take a look at?

[--Edit:Hm, come to think of it, since functions can be accessed from anywhere in the script after their definition, maybe camel notation would be the consistent thing?--]

Thanks guys!

I prefer MIT, because LGPL insists that any changed versions of the module need to be republishes as open-source, and if someone needs to modify one of my modules to add something game-specific, I don't think that is necessary. MIT simply asks for Credit and denies warranty liability.

That makes sense. I like that better, too.

I suggest your summary is made the only post ina locked sticky, with another thread (the rest of this one) linked to for discussion and fuller detail.

Good idea, will do once we agree on all points.

It should also be presented as "Suggestion" and clearly stated that we'd rather people published modules "as is" than not at all.

Yeah, I'll emphasize this more.

Still, developers should probably be encouraged to use relatively short but yet informative enough names. The problem with really long names is that it may bloat the source code making it a bit difficult to read.

Sure, I meant to ask if there's a technical reason for the 16 character limit.
I'll change "as short as possible" to "as short but as descriptive as possible".

I think it's up to the author and how they prefer to organize the internal structure of their modules.

I understand the reasoning for the distinction but I agree with you that this should be up to the module author. For consistency, let's suggest lowercase for module-script-only functions?
--Edit:
Hm, come to think of it, since functions can be accessed from anywhere in the script after their definition, maybe camel notation would be the consistent thing?
--

In my opinion, just make sure a GUI name is unique with prefixing it with a module name. But "g" will also be added infront, just to mention.

The reason I proposed the numbering is that (last I checked) GUI names can only be 14 characters long, so with the module name prefix there wouldn't be much left anyway for a descriptive name.

Personally, I don't mind their popping up and prefer to see all module related stuff on the list but since one may find it annoying and we also have the exact behaviour with GUI names ("g" infront), it may be the option too.

Glad you approve.

What I believe he means is:

Great, thanks for clearing that up for me!

- Create a new GUI, name it "MOUSEOVER"
- Remove its "Clickable" checkbox
- Put a label on it
- Set the label's text to "@OVERHOTSPOT@"
- Go to menu "Script" -> "repeatedly_execute" and put these two lines in:

Code: ags

function repeatedly_execute() {

  gMouseover.x = mouse.x; // move GUI to mouse position
  gMouseover.y = mouse.y;

}

You could've easily found something like this searching the forum.

Try enveloping your code with the StartCutscene and EndCutscene commands.

If you need a quick, simple solution, try Gilbot's OverHot script module.

In your example, RandomizeInt is a static function so would be called from the struct itself, not an instance, like this:
  MyStruct.RandomizeInt();

Now, SetInt is a non-static member function and so, since there are no static variables in AGS, wpInt and SetInt can only be accessed by an instance of the struct:
  MyStruct TheThing;
  TheThing.SetInt(4);

How do you think would the RandomizeInt function know the variable of which instance to access?

Do I misunderstand you?

You'll get that if your BG is a different colour depth to your game. There's not much I can do about it, as there's no way to determine a room's colour depth.

Just a reminder for you that now that AGS v2.72 has a Room.ColorDepth property you could add a check in the next version. Haven't tested yet if it would work, though.

Also, be sure to use the ' character, not the ' or `characters for contractions like "don't" and "can't" and so on.

SSH, why do you think the MIT license is better suited? I'm not well versed in legalese...

Also, I'm interested in this:

I noticed while doing the module, btw, that there's was no point in using protected when writing the module: just hide any local function and variables in an struct that inherits the "public" struct. It also effectively allows protected static functions, etc.

I don't quite understand what you mean. Could you elaborate a bit?


Anyway, I've noticed that the length of our discussions and the documents themselves seems to have made people reluctant to release their modules in fear of violating these guidelines.

And I agree the perceived amount of rules seems quite high at first. That's why I've written a short, easy-to-read summary of the guidelines that will hopefully encourage more people to release their modules.

Tell me what you think.

I need the games to have different music, and I'd rather not have the music as separate mp3 files.

Can you try this with 2.71 RC 4 and see if it helps at all?

So did this version actually fix the problem?
The changelog of AGS v2.71 RC 4 says
* Fixed Restore Game occasionally corrupting the managed object pool.
but I want to make sure it's related to this problem before I delete the bug reports.

COOL!! so you could make games like say, "Grim fendango" and "monkey island 4" ?

No, those games had static pre-rendered 2D backgrounds and real 3-Dimensional characters. You're looking for the Character3D plugin.

I think a complete rewrite was mentioned at some point. But since AGS 3 is a long way off, it's impossible to say for sure what will change.

Please keep on topic from now on.