Messages

[@SpeechCenter]

@SpeechCenter, I have little knowledge of this area (how Scripts class is used in plugin interface), and not much free time to investigate ATM, so I hope that you will come to consensus with monkey_05_06 before this request will be merged. I'd rather wait few hours (or couple of days if required) to see his reply (and maybe tzachs too, if he has anything to say) just to be sure everyone is ok with this.

** WARNING **
Following functions and variables are now deprecated. If you have any of them in script you will likely receive compilation errors.
Either turn Backwards Compatibility mode in Global Settings, or consider using corresponding property from Speech class.

I feel stupid, but I have not found the corresponding backward compatibility setting.

Oh, right, I forgot to mention the exact option.
It is Global Settings -> Backwards Compatibility -> Enforce object-based scripting.
This is because those changes (deprecations) disable few non-OO functions and variables.

[not]

The manual gives several examples of the proper format, namely EGO10.WAV, DAVI7.WAV, EGO1.OGG and EGO9999.OGG. (snore)
So no, I seriously don't understand how the sentence you quoted, illustrated by four examples, can be considered "not a clear instruction."
And your insistence to the contrary is starting to sound really funky.

Khris, lol, what we are arguing about?
I am not telling that no one would understand which format he may use from those examples. I am saying that people sometimes get erroneous assumptions, based not on their stupidity, but on their personal experience with computers, programs and documentation. What I mean here is that sometimes examples do not cover all possibilities, and some features may not be thoroughly documented.
Hence, some will look at this description and assume that they cannot use other number formats. Others may assume that maybe they may (at least there's a reason to try that out). Also, my opinion is that the definition of format should be explicit, and examples are only optional (provided as an extra help). That's why I don't see the suggested addition superflous (not that I see it ultimately obligatory though, this is just a matter to save people little time and nerves). And, for certain, I don't see it like "accommodation of every little shitty whim" (and yes, I was somewhat insulted by this, but whatever, this is my personal problem).


PS. Note about troll was a joke.

[not]

and I'm not changing my view that it's wrong to accommodate every little shitty whim

I am sure there should be a scientific name for this trick. Something about substituting a subject of discussion.
By the way, to be completely frank, this was the only reason I actually got myself into this argue (although at first I had no intentions to do so). I don't like be blamed in something I don't do. Especially, in an assholish manner like this.

E: Oh my... does this mean I was actually tricked by a troll?

or that manuals shouldn't be collections of speculative warnings but of simple, clear instructions.

Yet you seem to keep ignoring the point (or seriously don't understand??) that saying "followed by number" in the context of file name, while system requires precise number format (out of few common ones), is not a clear instruction.

But telling them how the format works does not require also telling them how it doesn't work.

But it doesn't state how it works exactly. And this is my point.

I also don't need a note that the elevator doesn't work with voice commands.

EDIT: I had to remove silly things I said here before. I did not say precisely what I wanted to.
I meant to tell that in our world people are used to the fact that elevators do not commonly use voice control. But what if they commonly did have voice control?
What I was telling in the post above is that having leading zeroes is not so uncommon in number formats. So why people should expect that they won't work here without any notice?

Similarily -

Accordingly, giving the example of EGO10 and DAVI7 does not require to spell out that adding leading zeros will not work.

These are examples of things that work, but there's no indication that others won't. And I believe that people have a right to ask: will it work if I put leading zeroes to make my files sort better? The manual does not tell that you can't. It does not tell that you must not. It tells only that you may do without them.

Let's not forget that in order to get into this situation, Adeel consciously didn't follow the manual and failed to process a warning message that clearly spelled out the exact problem.

Adeel's mistake was about overlooking a hint in the warning text. In my opinion it wasn't a mistake, in common sense, that he tried to use different format.

I'm sure you realize that's not a valid comparison.

Alright, I agree, these two cases are much different by the importance of the knowledge (and possible consequences of lack of one).
But they are the similar in that they give precise information of how engine work, and what it expects from user.

People may think differently; their views on how the number may be presented (what format) may differ. That's why it may be useful to specify it.
I am not telling this information has ultimate importance, but at the same time it is not useless notation made for idiots.
Especially in the light of the fact that engine normally recognized numbers preceded by zeroes in script, as I mentioned above.

[did]

If everybody else thinks that cluttering up the manual with shit like that is the way to go instead of expecting people to actually use whatever's between their ears, go ahead.

Following your vision of what documentation should be we probably need to remove these lines from the manual:

NOTE: You cannot use speech file numbers above 9999. That is, you can have EGO1.OGG all the way up to EGO9999.OGG, but not EGO10000.OGG or higher.

Really, why tell this to the user? They have brains, don't they? If they make voice tag >10000 and it won't work, they will realize it is an engine's limitation and will proceed using voice numbers accordingly.


Khris, you keep telling that no one is reading the manual. But while you can count those who did not read (properly, or at all), can you really count those who did read manual and therefore did not ask question on forum?

But putting all kinds of superfluous "contents is hot" warnings all over the manual is stupid.

But why is this stupid in this case? If program expects very precise number format, that should be reflected in documentation. Of course, it is not hard to make few experiments, but the sole fact that this may require experimentation already shows that the documentation lacks in detail.

Thanks for all the work on this. It's something I was struggling with in older builds, specifically with GUI buttons, and 3.3.0 has fixed a LOT of my problems. I'm still getting some weird issues with alpha blending, however. Specifically, if I use png buttons with alpha transparency in a GUI with a transparent background (bg image and color both 0) using the Multiplied Translucence setting, it leaves a 1-pixel wide faint pink border around each sprite.

This is something unexpected. Do you use the latest beta version (#8)?

I've tried setting the background image to a fully transparent image rather than leaving it as 0, but it just makes the phantom border a deeper shade of pink.

If the background was made of "magic pink" color, then this one is correct behavior, because when translucent image blends over the surface, it uses exactly the background color and does not consider pink as a "magic transparent" color. Instead you could try to create a 32-bit background image where every pixel is RGBA = (0,0,0,0) (shown as "checkered" color in many graphic editors).
If the background was precisely transparent (0,0,0,0), then this might be an error...

If there is something common in northerners, it is a love to hedgehogs.

["Scripts" class]

I wasn't contending that the Scripts type is never used for non-public scripts. I was asserting that the CurrentGame.Scripts object (which is of the Scripts type) is never populated with non-public data, or anything other than what shows up under the "Scripts" pane in the editor.

Err, well, I never said that CurrentGame.Scripts contains other stuff; in reply to Snarky's question I said that

"Scripts" class is used not only to keep user scripts

[exposed]

PS. To clarify: this "Scripts" class is used not only to keep user scripts, it may be used for some internal purposes too.

Are you sure about that? Because I'm terribly worried you're just making this all up as you go. AGS.Editor.AGSEditor.GetInternalScriptModules: These are never added to CurrentGame.Scripts. Nor are any of the Dialog.Script objects. Nor are the UnloadedRoom.Script objects. The Scripts class is used for collections of scripts, but the exposed Scripts object never contains anything except the scripts shown in the ScriptsComponent. To clarify.

Find Game.ScriptsToCompile. It is of "AGS.Types.Scripts" type.
Before game is compiled this collection is filled by all other scripts:

Code: csharp

foreach (Script script in GetInternalScriptModules())
{
    CompileScript(script, headers, errors, false);
    _game.ScriptsToCompile.Add(script);
}

foreach (ScriptAndHeader scripts in _game.RootScriptFolder.AllItemsFlat)
{
    headers.Add(scripts.Header);
    CompileScript(scripts.Script, headers, errors, false);
    _game.ScriptsToCompile.Add(scripts.Script);					
}

CompileScript(dialogScripts, headers, errors, false);
_game.ScriptsToCompile.Add(dialogScripts);

Well, maybe except room scripts, frankly I could be mistaken in regards to them. E: right, I am wrong, because rooms are compiled separately from anything else.

Formally speaking, manual does not provide a strict format description, it just sais "ID number". Can engine parse the number with leading zeroes correctly? Who knows (in some other cases it does, e.g. speech numbers in text). Less technically savvy person may not even consider this as a possible problem.

The manual currently states: "The file name is made up of the first four letters of the character's script name, then an ID number".
What's wrong in adding, for example, "...then an ID number with no leading or trailing zeroes or padding of any kind"?

PS. BTW, there was a topic on improving the manual:
http://www.adventuregamestudio.co.uk/forums/index.php?topic=46471.0

Out of curiosity, how? Doesn't the editor always create and remove headers and script files together?

Dialog and room scripts do not have headers.
Also, there is at least one header created internally (where all the system symbols are defined).

PS. To clarify: this "Scripts" class is used not only to keep user scripts, it may be used for some internal purposes too.

Yes, that is all. When game is (re)built, AGS editor uses the one acwin.exe found in its folder.
You need to rebuild your game once again after you pasted new file there (unless you already did that).

Hmm, I was about to say "Dr. No", but something is not right here

[+5]

It appears that room volume can be set in range between -3 to +5. Tested in 2.62.
+4 and +5 values are only settable with SetMusicVolume() function (which sets room volume, not general music volume).

Manual does not mention this.


EDIT: No, the first assumption was wrong.
Upon comparing with 2.62 test game I can hear that 2.62 music plays louder with the same volume setting; this means that +60 volume units are added to compensate this difference. (I do not have 2.62 code, but who knows, maybe it was made like that back then).

Also, then newer 3.3.0 engine should produce same results as 2.62. What I'd like to know, if there's a problem with dropping music volume: did that dropping worked well in previous versions of AGS, before you made an import (from 2.72)?
If it worked well prior to 3.3.0 (or 3.2.1), but no more, this means that it is rather volume drop that does not work well.
If the range of music master volume has changed from 0-100 to 60-160, then we'd need to fix volume drop accordingly.

EDIT AGAIN: err, no, something is wrong, I need to think more about this.

(edit) As I recall, AGS has these 'room music levels' that nobody ever seems to use much; these probably apply a modifier to the music's overall volume, and the lowest of those might be -60? I mean SetMusicVolume, which has a scale of -3 to +3; it wouldn't surprise me if this maps to -60 to +60 internally. If so, these would need a boundary check to treat totals of less than zero as zero.

Ohhh. Well, in such case this is made not right. I found a code where a room modifier is applied:

Code: ags

int newvol=play.music_master_volume + ((int)thisroom.options[ST_VOLUME]) * 30;
if (newvol>255) newvol=255;
if (newvol<0) newvol=0;

I think this may be fixed by changing this to something like

Code: ags

int newvol = play.music_master_volume + room_modifier[thisroom.options[ST_VOLUME]] * 30;
if (newvol>100) newvol=100;
if (newvol<0) newvol=0;
newvol = newvol * 255 / 100; // convert unit range

Yes, this will require to keep master_volume in 0 - 100 range throughout the code.

It's causing an issue for us that Speech.DisplayPostTimeMs doesn't work with voice samples but only with text

I hope you mean Speech.AnimationStopTimeMargin? DisplayPostTimeMs should work with voice.

Also, it's been shown earlier in the thread that the old function SetMusicMasterVolume() cannot reduce music to zero, because it takes a value between 0 and 100 then internally adds 60 to this value before using it. Would you mind if the function were to accept values from -60 to 100, so that calling SetMusicMasterVolume(-60) does result in an internal volume of -60 + 60 = 0?

I would like to understand why it was made that way. Perhaps there was a change in volume units? Any ideas?

Interesting. It appears that the bug in dialog script view is not related with the dialog order bug. It takes place even without changing any order.

To reproduce:
1. Load game project.
2. Open any existing dialog for editing (or create new one, if there's none).
3. Right-click on pane's header, and choose "Close". Dialog script is closed now.
4. Re-open same dialog. The script will not have any syntax highlighting.

I think this is because Scintilla (script) control becomes deinitialized, or something like that.