Messages

Did you notice you have to change your sprites after you finished an animation?
No problem! Just edit your graphics and save them in the original place on your PC and then click on "Import sprites from source" by selecting and right clicking on the Sprites you want to change! No need to create a new view from scratch!

Oh I just noticed that this thread is really old after I posted it, I'm somewhat too late.

While testing the new beta version, and the sprite import, in my project but also in new projects, I came across a few bugs that the new beta version still has. I'm sure you guys are working on it, and I don't know if that is interesting to you, but this are the things that did not work correctly:

When I try to Assign Sprites to a View by Right Clicking on them (in any project), I get a big Error Message:

These two:

https://drive.google.com/file/d/1XWoiLcPGc1KfyYYAhXTN3lrff3V5-rWJ/view?usp=sharing

https://drive.google.com/file/d/1_Sj3JxRRv9bdvkE_HI0ZHm7h5GGoJmYi/view?usp=sharing


In written form:

Error: Input string was not in a correct format.
Version: AGS 3.5.0.16

System.FormatException: Input string was not in a correct format.
   at System.Number.StringToNumber(String str, NumberStyles options, NumberBuffer& number, NumberFormatInfo info, Boolean parseDecimal)
   at System.Number.ParseInt32(String s, NumberStyles style, NumberFormatInfo info)
   at System.Convert.ToInt32(String value)
   at AGS.Editor.SpriteSelector.SpriteContextMenuEventHandler(Object sender, EventArgs e)
   at System.Windows.Forms.ToolStripItem.RaiseEvent(Object key, EventArgs e)
   at System.Windows.Forms.ToolStripMenuItem.OnClick(EventArgs e)
   at System.Windows.Forms.ToolStripItem.HandleClick(EventArgs e)
   at System.Windows.Forms.ToolStripItem.HandleMouseUp(MouseEventArgs e)
   at System.Windows.Forms.ToolStripItem.FireEventInteractive(EventArgs e, ToolStripItemEventType met)
   at System.Windows.Forms.ToolStripItem.FireEvent(EventArgs e, ToolStripItemEventType met)
   at System.Windows.Forms.ToolStrip.OnMouseUp(MouseEventArgs mea)
   at System.Windows.Forms.ToolStripDropDown.OnMouseUp(MouseEventArgs mea)
   at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
   at System.Windows.Forms.Control.WndProc(Message& m)
   at System.Windows.Forms.ScrollableControl.WndProc(Message& m)
   at System.Windows.Forms.ToolStrip.WndProc(Message& m)
   at System.Windows.Forms.ToolStripDropDown.WndProc(Message& m)
   at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
   at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
   at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)


So now I have to add every single sprite manually to a view loop by clicking on the "Create new Frame" button in the view tab.
Because the "Create new Frame" button moves further to right for each frame you add, and it's kind of annoying to follow the the button with your cursor to keep clicking, I avoided that problem by restoring down the program and adjusting the proportions so that the two sides, left and right, are very close together, because then you keep seeing the button on the same spot and you can just keep clicking it and adding new sprites. But when I did this I noticed another tiny bug: When you restore down the program like that and "squeeze" the right and left side of the program window together, and then click on the work space, sometimes when afterwards you maximize it the proportions of the property panel gets messed up. Meaning that the right column, where you read and type in the property values is moved to the right and you cannot see or read the values anymore, so I have to re-adjust that after I maximized the program again.


Another bigger bug is that everytime after running the game I get (in all projects, no matter which room or game) this error message:

https://drive.google.com/file/d/1URyVAO30_9AWnYVe17V44bn8zlSGKcq6/view?usp=sharing


Also, sometimes when you open a sprite folder, the tab all of a sudden switches by itself and I would find myself on a view tab, and I would have to click on the Sprites tab again to view the sprite folder I opened.


And I think a great thing would be to add an optional x- and y- offset for the FollowCharact(_EXACTLY) function, because this way you could very easily add shadow below the character without messing up baselines, it would be really useful for that. As for now if you add a z-Value to either the original character or the shadow character, it does never change the distance of the characters to each other, the program always aligns them on their original Baselines, so you never have an actual offset between the two, and you can't just create a shadow character below the original character to follow him around. This kind of leans in to another thread I posted, but we talked about the new version here, and if you think too that this might be useful, I think it'd be a great feature.

Hey I installed the latest version of AGS I found (v 3.5.0.16).

So the sprites that were replaced by the dummy blue cup, that was mostly an unlucky coincidence. With the bug I had when I saved new sprites, it would not save them but I would only get those blue dummy cups when opening the project again. But only sometimes it would save also some of the old files as blue dummy cups, that usually were saved correctly. So apparently just before I uploaded the game I saved the game and the sprites were saved as blue dummy sprites, but that was all due to the bug I described.

However, after installing the new version, I re-imported from source ALL my sprites, just to be sure.
However I still keep getting the same warning that you quoted in your message everytime I open the project, even though I have not a single blue dummy sprite anymore.

The good news is, now I CAN save the sprites and I CAN add new sprites, which makes me really excited, because I can finally add some cool, elaborate animations to my game! The work you guys have done in the new beta version on the sprite import and organization is really visible. Sprite folders are loaded faster, and the import is way faster, and does not slow down when I add dozens of high resolution sprites.

With that said, the initial warning that you also saw remains, which does not hinder my working, but is maybe just annoying.
Do you want to get to the roots of this problem?
I might re-upload the game with the correct sprites if it would really help, but I don't think it is necessary, also because you could simply add ANY kind of sprites as place holders for the blue dummy sprites I believe, in order to test it. It does not change anything to the cause of the problem.

I mean I trust you with this, and I think everyone, me included, can only profit if you can improve the program.
I PM ed you a link with the game file.
Well at least the sprite file tripled down in size after compressing the sprite files. The whole thing is about 4GB big.

Alright

I don't know if I got all the information right and if I understood the whole problem, but would using global bool variables add some helpful flexibility?

For example you have a bool for every language:

(bool beng, bool bpor, bool bfre...)

Then whenever a character says something at any point you always write as follows:

if(beng==true)
{character.Say("&3 I'm hungry!");}

else if(bpor==true)
{character.Say("Eu estou com fome!");
//or: Por.Say("&3 Eu estou com fome!");
}

else if(bfre==true)
{character.Say("J'ai faim!");
//or: Fre.Say("&3 J'ai faim!");
}


This gives you way more flexibility. You can change the language at any time and at any point in the script.

And if you want to change the language for a certain character separately, let's say for "Fred" for example, you can add another bool group:
(bool bfredeng, bool bfredpor, bool bfredfre...)

And whenever "Fred" is talking you script with the according bool variables:

f(bfredeng==true)
{cFred.Say("&3 I'm hungry!");}

else if(bfredpor==true)
{cFred.Say("Eu estou com fome!"); }

else if(bfredfre==true)
{cFred.Say("J'ai faim!");}

So then when you want to change the language for all the characters (by clicking a button or anything else) you simply change all of the bools, e.g.:

bpor=false;
bfre=false;
beng=true;

bfredpor=false;
bfredfre=false;
bfredeng=true;

...

which will still give you the ability to change the language for only one character at any point in the game.


Also, do you need different audio groups and names for every language?
Could you not simply, if your character speaks for example 40 times during the game, and so you have 40 audio files for every language, script it like this and add every language under the same speech group name:

if(beng==true)
{character.Say("&3 I'm hungry!");}

else if(bpor==true)
{character.Say("&43 Eu estou com fome!");
}

else
{character.Say("&83 J'ai faim!");}

That was my idea...

Okay I figured it out.

But I guess it does not accept online google drive links for photos.

                                               

Hi, I'm trying to add photos to threads but I have no clue how. When I click on the image icon I only get (img)(/img) in square brackets. I have no idea what to do with that.

And I didn't find anything about it in the forums.

What exactly do you mean when you say "we will try to investigate"??

Do you have like a whole lab team working on it?? 
And I mean, how can you investigate it if you don't have my game?

So when I open the project and open the Sprite folder, oftentimes it does not show the sprites, and my mouse curser turns to loading.
And then I wait a long time, 10 minutes, nothing happens. The only thing I can do is I restart the program and the project, go into the sprites folder, and repeat until the sprites are shown. Because sometimes it works. I had this problem only in the beta version, not before. The interesting thing is that when the sprites are not shown, I can still open the sub-folders, and even when the rest of the sprites are not shown, I can open the sub-folder where I added and saved two sprites successfully in the beta version, and they are being shown.

The freezing itself occurs when I try to import sprites.
So I imported multiple sprites over the right click, import sprites... option, and after selecting the images the import window opens, where you can select to use alpha channel and change other import details.
Then when I confirm and click on "Import All" it freezes. When I had the problem that the sprites were not shown in the sprite folder, it froze immediately. When I restarted the program several times until the sprites were shown in the sprite folder, it imported 3 sprites before freezing (you know how the sprites are being displayed one after another in the import window while being imported). In any case the import window and AGS freeze, and if I click around after several minutes, windows sends me this message that the program stopped working:
https://drive.google.com/file/d/1mFZXhC9FOl6_iP2NgE_yN-pM2e4aHIUB/view?usp=sharing

And I waited I guess 20 minutes and nothing happened. I don't think waiting any longer will do any good.
This is some tricky business here!

The last error message I saved was this one:

https://drive.google.com/file/d/1VlD_Bnz8kiGYPr33C6C2hvJ8n4y4p_-m/view

No, it doesn't anymore. It just freezes and doesn't respond anymore.
Could be related to the beta version?

The error messages I received before I already posted them above in this thread.

Okay, no worries then.

For most view changes it is helpful to change the sprites' orientation in my game and use all the previous tips and ideas, but I still have one animation left for which I haven't found a better solution than actually using the dummy and the "PlaceOnWalkableArea" function.
That's when the character is being catapulted by a big metal spring. He is being catapulted in "3d" space so to speak, diagonally to the back of the room, so he's walking against the spring and then being pushed by the spring forwards and flying away, and becoming smaller while flying away obviously. So when the character detaches from the spring, the solution with the "PlaceOnWalkableArea" function is the best one in my opinion for two reasons:

1) Editing the sprites messes up the scaling: If I aligned all the sprites to have the same y-baseline (the sprites with the metal spring being bent by the character, and the sprites with character detached from the metal spring by himself), it would completely mess up the scaling of my character, because the baseline of the spring is significantly bigger (and closer to the screen) than the character himself, so the character's scaling has to be smaller than the scaling of the metal spring. Fixing that through ManualScaling would be extremely messy because then I cannot use the intuitive scaling of the walkable areas anymore in the follow up and would have to create a complete manual Scaling system, for every single Walkable area individually, and that would be really messy.
And just in general having too big of a z-offset for my character might affect the scaling too much.

2) When you place the metal spring somewhere, even when the baseline of the metal spring is inside the walkable area, the "catapulting" end of the spring might still be outside the walkable area, because the spring is lying diagonally towards the back of the screen in space. So when you are catapulting yourself, you will end up outside the walkable area. Now when that happens and the spring is lying in front of the truck for example with the end outside of the walkable area, I will move the character first into the walkable area before playing the view that shows the character "crashing" against the truck. Maybe you could also move the character while animating the crash view or after it. Because if you don't move the character, then the character is floating in space in front of the truck after the crash animation, and is standing outside the walkable area.

I don't know if there's a better way to do this.

Now last time I tried in the beta version the program just crashed and freezed  and I have to close the program.

No need to apologize; I was actually hesitant to post that because I thought I might not have the full picture.
It's just that after doing this for so long, I always see XY problems everywhere

Just don't be a dick when sharing your ideas, like when you said we were just " messing around".
That's one of the main forum rules to give constructive feedback.
You don't know everything and even with the right sprite orientation I still need the dummies and function.

Have anyone tried LockViewAligned and LockViewOffset as an alternative to manually add empty regions to sprites?

E.g. LockViewAligned:

The main purpose of this command is that it can align the new frame to the previous one. This is particularly useful if you want to go from the character's normal walking view to a specific animation - since characters have the central point as their 'axis', if you have a wider animation then it can be difficult to stop yourself getting a jumping effect when the animation starts.

Doesn't really help me in my case.
It simplifies placing the character in the right place and can make a cleaner script, but the character still ends up outside the walkable area this way.

I'm still fascinated by the topic of the walkable areas though! 

Okay, I have to say you guys are right. My bad. And sorry Khris, you were right, I could have arranged my sprites way better to avoid this problem.

At one point my character is shoving a big rock in front of him.
Which adds a big shadow below the character and the rock, that I added in the view animation,
which means that the character center on the y-coordinate is dislocated, even if the character remains centered on the left and right.

Of course there are multiple ways to manage that and I might figure out a way to  add the shadow separately as a different character that follows the first character so that I can keep the character position centered to the same spot, but helas, it gets complicated again.
So I just choose to dislocate the character during the view switch, and that's the problem I was dealing with right now.
When you create a game on the go, and don't know what's gonna come in the end, you sometimes get new ideas, and it's sometimes easier to just dislocate the character instead of readjusting all of your previous sprites because you didn't know in the beginning that you gonna do a certain type of animation. Also it's really impractical to have the character's center dislocated on the y-coordinate in the main walking view, because then he always walks above the mouse click and not exactly where you clicked, and you have to take that into account as well. So the whole thing is just way more complex, and just adding the advice to center your character is not really helpful for the issue I had. So if my question was how to center and animate my characters better during view switch, I would have done so. And if Khris wants to talk about that he can do so where it's needed and actually helpful, but it's not what this thread was about.
So I prefer focusing on the stuff here in the forum that actually helps me with my actual and concrete problems with my game.

Keeping the character's  alignment point centered to the base point of the sprite is a great idea. But that was not my concern here, so it's not really the issue...