Messages

That's the easiest thing to look up in the manual you know

I wouldn't say it's the easiest. I always typed in RemoveInventory or RemoveItem when I first joined AGS. Lose isn't exactly the term I would use to describe that function since Lose isn't the opposite of Add. Remove is.

But he did use word Lose in his question, so it shouldn't have been a problem for him to find it.

[Edit: Rewrote my post and added some more]

Edit: Rewrote my post and added some more

Script Extension:
If we were to have scripts for each element like Characters, GUIs, Rooms, Inventory Items. We would need a way to access the Public script functions and elements but only ones that are Public.
So I was thinking a "Script" extension for each Class would be most logical.

For instance accessing room script elements:
rBeach.Script.doFunction();
rBeach.Script.thisIsAStruct.count++;

And obviously objects and such should be accessible even if you're not in that room:
rBeach.oDesk.doExtenderFunction();
rBeach.hPainting.doExtenderFunction();

Then for Characters:
cJoe.Script.JoeHasTalkedToBilly = true;
cJoe.Script.doFunction();


Inventory:
That "Display multiple icons for multiple items" shouldn't be the end all option. It should be item specific. If I had the item Coins, I wouldn't want multiple coins in my inventory. But if I had the item Mug, I may want it to show every mug I have, just like in Monkey Island.

One possiblity is to have inventory items like a Class. So if you had 3 Mugs, they all have their own copy of the variables and such from within the script. So iMug[0].Script.Health  would be different from iMug[5].Script.Health  (Health being an Integer variable)

So that could be one way you manage inventory items better. Where an inventory item 'could' have a repeatedly execute always, if needed. Then you could count down the Health of each Mug as the Grog in it eats away at it. Changing the graphic of the Mug item.


Obviously the Script extender wouldn't be accessible to the ID class. Character[1].Script  wouldn't be allowed. Since accessing the functions and elements for a character would only need to be done for that individual object only.
You'd just use the main script for each element type to make an extender function, or struct, or whatever that would work for all objects.

If for some reason a Character.Say in skipping mode still causes a short wait, many of them could cause a considerable lag. This is beginning to sound like a bug, it's just weird that nobody else has noticed it yet.

I realize this post is a little old but I had to respond. It's not exactly a bug, it's actually doing what it should do. If the Say command blocks the game for 5 seconds to show you the text but was within a skipped cutscene, the engine will run 5 seconds worth of repeatedly execute always calls plus any character, object animations.

The only real way around it is to check before the Say command.

Code: ags

if (!Game.SkippingCutscene) player.Say("Line1 Blah blah blah");
if (!Game.SkippingCutscene) player.Say("Line2 Blah blah");

It seems redundant to duplicate that code, but AGS is doing exactly what it should be doing. Since during the Say command you may have code in Repeatedly Execute Always that does something if the character is on a specific frame.

Because PlayMusic is now obsolete. Look in the manual for Play.

You add the music file into the audio branch of the project tree. Then simply call it by name like so:

aExplosion.Play();

Have you not looked at a single previous post of yours and noticed that you're typing in the quote box?  :'(
Or you're deleting the ending [/quote] which makes your whole post a quote.

What I don't understand is just because he went over the planned $400,000 budget, doesn't mean the rest can't be profit.

mmmm apparently you have troubles reading. But I suppose I never did walk you through what that file was. You simply import it into AGS by right clicking on scripts and then import module script.

This is hardly an 'awesome' video clip but my step brother just uploaded this to YouTube and I couldn't not share it with you guys.
I was the camera man, editor, and director all of these videos. I made them in high school roughly 10 years ago - except for the first one which is like 5 years ago.

First video is a silent film (music video) type deal that my step brother made for his class - it's the most recent and my favorite.
The second one is a sniper music video deal it was the first one we made - my second favorite but the ending is terrible. My twin brother being choked to death with a large afro.
The third one is the second one we made, it's the wackiest too. We had no idea what we were doing until we got out into the field and started filming. lol It's actually kinda terrible.
And the last one is a commercial type deal I had to make. It was mostly terrible because I accidentally filmed over half the good scenes that we did. Like the car driving over the camera and other good stuff (the battery died as I was rewatching the film on the camera - then forgot about it once I recharged the battery). I had no time to reshoot, had to use what I had.

We look terribly young in this.

http://youtu.be/ifQC8NfnxFw

I have no idea where to begin with commenting on Rick's PDF of ideas but it's pretty close to how I would like to see the future AGS. I hope to comment more on it some other day when I have more time.


But for now I have been thinking of scripting and how to allow more advanced players to get under the hood.

For example, where Character.Say is a standard function with AGS, you could actually create your own Character.Say function that overrides the default AGS function like so:

Code: ags

public override void Say(this Character c)
{
  //whatever we now want Say to be instead
}

The only tricky part is how to decide which script is the master script that gets the override. That's assuming you had 2 modules with an override Say function.

What would also be nice is being able to have a partial function for other purposes.

Code: ags

public partial void Say(this Character c)
{
  ACharacterHasSaidSomethingThisManyTimes++;
}

etc..

mmmmm Here's a much nicer solution, a module that uses extender functions for the inventory items. Eg: inventory[17].Animate(0, 1, eRepeat, eForward);

The only thing I didn't do was blocking animations, a flipped frame in the view, or frame sounds. I was too lazy. But this works for blocking animations:

Code: ags

iPizza.Animate(0, 1);
while (iPizza.Animating()) Wait();

I just don't recommend doing that if eRepeat is set, unless you have the inventory stop animating at another point.

Here are the extender methods:
Inventory.SetView(int view, OPTIONAL int loop, OPTIONAL int frame);
Inventory.Animate(int loop, int delay, OPTIONAL RepeatStyle, OPTIONAL Direction);
Inventory.Animating();
Inventory.StopAnimating();


http://www.bryvis.com/entertainment/other/agsf/InventoryAnimate.scm
(right click and save as)

Let me know if it has any issues, I didn't test it to the extreme, but it seemed to work just fine.

I sorta understand why it does this, but it should only really need to be doing this if the object is using scaling, tint, flipped, etc.

I imagine that's why it bloats the game each time an object is assigned a sprite because there are two instances of it. The original and the scaled, flipped, tinted, etc version.

[179,240 KB]

I haven't a clue where to post this considering you're all hoping to have new forum in the future. But I'll point this issue out in case it hasn't been noticed before.

I was doing some tests because of this thread when I discovered this multiple sprites in memory issue.

I create a dynamic sprite that is 6400x4800. The game memory usage becomes: 179,240 KB
I then assign object[0] the above mentioned dynamic sprite. The game memory usage becomes: 419,756 KB
I then assign object[1] the same sprite. The game memory usage becomes: 660,272 KB
Then the same with object[2]. The game memory usage becomes: 900,792 KB
..etc etc..  each time I run this test the memory usage is slightly larger or smaller - which I imagine is expected

There is approximately 240,516 KB difference every time a different object is assigned the same dynamic sprite.
It's significantly worse running the game with Direct3D.

Why would AGS do this? Discuss. Does this need to happen for some hardware reason I'm not familiar with?

Edit: I figured I'd check a sprite that wasn't a dynamic sprite and assigned it to 3 objects. It does the same deal as above.

I'm more shocked that people actually send Dan pm's.   

You only draw the fog on screen when it's visible to the player, then draw the fog on the minimap only when it changes. You should store the minimap as a dynamic sprite (if you aren't already - I would hope you are, it's the most efficient way) and only change the individual pixels of the minimap when needed.

The best way for the minimap, in my opinion, is to store the colors on an array per pixel along side with the dynamic sprite of the 'current state'. Then whenever the fog is light, medium, dark, you change that single pixel to the appropriate color basing it from the color data in the array. That way you aren't using GetPixel anymore than once when the level loads up. Then you're only using DrawPixel on the minimap dynamic sprite Only whenever the fog actually changes for that single pixel.

Then have a separate dynamic sprite with a Transparent Color background that is layered over top where you draw the colored pixels for where the characters are. This should be done along side with the single While loop for the characters; because you should avoid doing a while loop multiple times wherever possible.

Edit:
And you know what is even faster? Is what Calin said. Because drawing on a large background is much slower than drawing on multiple dynamic sprites that are the size of the screen. But only drawing on these dynamic sprite if that section of it is visible to the player. Then when the 'viewport' changes, you move the sprites around. You don't even need to draw on the background at all either, just on these sprites which can be Objects. Only because using DrawImage on the background is should be slower than AGS displaying the object that is using the dynamic sprite (although I've never benchmarked the speeds on this).

You'd only need 4 objects and have them change to whatever background chunk is needed, then swap the XY of that object to the other side. It's the most efficient way that I've somewhat experimented with.

Edit:
Now that I've thought about this more I really want to run a speed test between the two. Fully doing it Calin's way with a gigantic sprite the size of your map, or multiple sections of your map on individual chunks. Either using 4 objects to display them, or simply drawing it to the room's background; with the room's background being equal size as the game resolution of course. One day when I get a moment, I'll check the speed between the two.

My thoughts are that drawing to a gigantic sprite should be slower than drawing to a smaller sprite, or multiple smaller sprites. That's what I need to run a speed test on.

Just direct it towards Quebec if you do.   

Brace yourself, Canada! Here comes the penis!   

Hey.... Nobody respects Canada.  :'(

Excellent! I've always wondered what the Ben sounds like. Hopefully there will be a lot of grunting and "Ungh" sounds.

Tino, if you ever need an additional beta tester, I'd gladly offer my services.

I definitely agree that when the game is in a window it should be able to be resized or can be maximized. Also with Alt+Enter to enter/exit full screen mode while you play.

That definitely is Slither. I was just about to post a hint, but you posted while I was typing.
My hint was going to be Nathan Fillion.

I'm not sure if anyone will know this. It's pretty recent.