Messages

Right on. Thanks guys. I'll take a look at them when I haven't been drinking. (I'm normally sober... most of the time )

Ahh.. Now I see the light. When creating a new project I have the choice between Visual Basic, C#, C++, etc. Hmm. Which one is the best/easiest format for creating a normal windows based program? I imagine Visual Basic?

I just call it FF3 because that's exactly what it says on my SNES cartridge.

And I'm not talking about the active time battle, I'm saying that there's no indication of a battle at all. If there weren't health bars for the enemy and yourself, I'd never even know that anyone was damaging anyone. The character being attacked doesn't even flash, or shake, or tint red, or anything.

It doesn't look like there's a battle going on at all. All I see is fireballs being held in all their hands and the two human characters each do an arm dance after you click to attack.

There isn't even any indication of anyone attacking or being attacked. In the only Final Fantasy game that I can really remember well because I really loved, the characters would jump at the enemy. Then there'd be some form of damage indication on the enemy and vice versa. Even a total hp damage count popping up from the character.

http://www.youtube.com/watch?v=hKBvaylsUCY

Also, I'm not sure if it's because of the video being compressed, but it looks like your battle GUI is still at 95 transparency or something like that. It looks like it's still visible and I would be very annoyed with that while playing. But it could be just the video's compression keeping artifacts of it visible.


Not to sound rude, but it looks very boring at the moment. You've definitely improved your graphics and overall battle interface, but it's still missing something that actually resembles a battle.

Oh, my apologies, I didn't know there were any differences between any of the VS applications.
In the about section the graphical header says Visual Studio 2010 Ultimate, Version 10.0.30319.1 RTMRel. And when I created a new application I selected "Windows Forms Application".

Or am I still giving the wrong information?

I'm completely new to Microsoft Visual Studio 2010, just downloaded the trial version last night. It actually looks pretty simple to grasp with all the subs and such. I'm assuming it's very similar to c#.

Anyway, I'm wondering how to 'correctly' draw a rectangle? I'm trying to do something similar to the drawing surfaces in AGS. Most of the google searches I find say that if you move a form over the drawn rectangle with the method they show, it will erase it. Then they say the correct method is to use the paint approach, but no one seems to like to show that method. Do any of you know the correct method or a tutorial that I can learn from? Thanks!

Just to go a little off topic, I'm in charge of making work schedules now for almost two dozen employees and the program is so unbelievably horrible and frustrating to use that I'd rather just make my own. I can't set it up to notify me if I don't have a cashier between opening and closing. Or to even have it tell me that the person I'm putting on cash doesn't have training for it. Etc. That's one of the many many things I'll be adding.

God you look hot. Put that picture away before Dualnames gets excited.

Let's see if I have this correct..
dJasper1 is a bool that you're setting to true once you've talked to Jasper, and not the dialog name itself, correct? In that case, something like this, I imagine:

Code: ags

function owatercooler_Interact()
{
  if (dJasper1)
  {
    cNancy.Say("What the hell do you think you are doing?");
    player.Say("*sigh*");     
  }
  else
  {
    player.Say("Don't know why I would need that now.");
  }
}

If you've talked to Jasper, (dJasper1 == true), Nancy yells at you and you respond with a sigh. And that will run every time you interact with the cooler after talking to Jasper.

Otherwise (else).

The player will tell you he doesn't know that he even needs it, and he'll say this every time you interact with the cooler before talking to Jasper.



Conditions are pretty easy once you start looking at them logically.
if (theVariable == 10) doThis();
  else if (theVariable > 10) doThat();
    else doWhatever();

For that line of code, you're checking an int variable named 'theVariable' (an 'int' is a variable that stores numbers. Anywhere between â€"2,147,483,648 to 2,147,483,647). It'll run in the order you read it, from top to bottom.

- If theVariable is equal to 10, it will run the function: doThis() and stop there without proceeding to the else's.
- If theVariable wasn't equal to 10, it will run the next else in line which is checking if theVariable is higher than 10. If it is, it'll run the function doThat() and stop there.
- If theVariable wasn't equal to 10 and wasn't higher than 10, it will run the final else (which means theVariable is lower and not equal to 10) it will run the doWhatever() function.

Sorry for your loss.

And honestly, I'd prefer to lose a loved one in a much quicker fashion (heart attack). If you watch and care for them for several years while they struggle to survive, it'll make it that much harder to remember them for who they are. Instead you'll remember who they became. It can become a burden, and no one wants that responsibility or hardship for their loved ones or children.

['woflies']

Has everyone seen the new 'woflies' that Notch and his gang are working on?
It looks as though you can tame them with a bone or meat and they'll become your pets. They'll kill your enemies and such. They even shake the water off themselves just like a real dog.

Once they become tame, they won't despawn. I wonder what would happen in multiplayer. Would they sit and wait for you to log back on?

I definitely agree with Ben. I feel like a kid again just looking at these screenshots. You've turned the Monkey Island style into something of your own, which is great.

Yeah I figured it was the 8 character limitations of dos that made it Game.agf in the first place, and that it's within its own folder making it impossible to confuse one project from another.
The only issues I can see now are perhaps the accented characters and such. I can't remember the technical term for them.

It's definitely not a huge hassle. I do open multiple projects up at once all the time and I mostly figured it was a quick fix with the editor.


Also, since I'm posting in here again. You know what feature I really like with XNA. I like the ability to press the back button on your mouse to return to where you previously were in a script. Whether you moved away from your current location by jumping to a function or simply scrolled away from where you were previously editing the script, it will return you to where you were.

It's definitely a very speedy feature, I would love to see that with AGS.

Good spot Monkey. I changed it in my script above. I simply copied his code without reading it fully I guess.

First off, sorry for the missing brace on my code above, I wrote it all in the browser. Glad you didn't have much trouble finding out the issue.

Now for your current problem. The reason why it grays out the graphic when you deselect it and makes the graphic normal when you select it, is because that's exactly what you're telling it to do.

Snippet from your code:

Code: ags

if (player.ActiveInventory == clickedItem)
{
  player.ActiveInventory = null;
  clickedItem.grayGraphic();
  return;
}
else clickedItem.normalGraphic();

Here you're checking the Active inventory item and seeing if it matches the currently Clicked item. Then you're removing it from being the players active item, and you're then using clickedItem.grayGraphic when you should be using clickedItem.normalGraphic.

Because you want it to deselect the current inventory item if you're clicking on itself, therefor it should go back to normal graphic. And the else should be clickedItem.grayGraphic();


But anyway, overall it should look something like this (I believe):

Code: ags

function on_mouse_click(int button) 
{
  InventoryItem *clickedItem = inventory[game.inv_activated];
  
  if (IsGamePaused() == 1) 
  {
    // Game is paused, so do nothing (ie. don't allow mouse click)
  }
  else if (button == eMouseLeftInv)  // left click on inventory item
  { 
    if (mouse.Mode == eModeUseinv && player.ActiveInventory != null)
    {
      if (player.ActiveInventory == clickedItem) //deselect the inventory item when clicking on itself
      {
        player.ActiveInventory = null;
        clickedItem.normalGraphic();
        mouse.Mode = eModeTouch; // <-- Change this to whatever default for mouse.Mode should be when inv is deselected
      }
      else clickedItem.RunInteraction(mouse.Mode);  //run the inventory on inventory interaction
    }
    else if (mouse.Mode == eModeTouch)  //select inv item
    { 
      player.ActiveInventory = clickedItem;
      clickedItem.grayGraphic();
    }
    else if (mouse.Mode == eModeLookat)  //look at inv item
    { 
      clickedItem.RunInteraction(eModeLookat);
    }
  }
  else if (button == eMouseLeft) 
  {
    ProcessClick(mouse.x, mouse.y, mouse.Mode);
  }
  else // right-click, so cycle cursor 
  {   
    mouse.SelectNextMode();
  }
}

It's been quite a few months since I've last tinkered with inventory clicks and such, but I believe this will work... I think.


There's a few things I changed around. You had the if game is paused mouse clicks below your inventory. Now, if your inventory window actually does pause the game, then you did have it in the right spot and you can just simply move the pause below it. Otherwise, you don't want to be able to select inventory while the game is paused, only if your inventory window doesn't pause the game.

Your indenting and brace locations seem kind of erratic. You'll actually notice that once you start to use proper indentations, you'll actually be able to read and understand your code so much faster.


Also something I didn't mention earlier, you'll have to change the default graphic for an inventory item once you pick it up. Something like so in the on_event function:

Code: ags

function on_event (EventType event, int data)
{
  if (event == eEventAddInventory) inventory[data].normalGraphic();
}

It'll change the graphic to normal every time you pick up an inventory item. You could do it whenever you Lose an inventory item as well, but I wouldn't bother unless you needed to.
The reason you should change the graphic to normal is so that if you were using a currently selected item on something and then removed it from your inventory. If you picked it back up, it would be gray.

Why not just eliminate the ability to use an inventory item on itself? It's quite odd that you'd even allow such a behavior. Why not just have it deselect the inventory item whenever you click it on itself.



If you really wanted to get more professional, how about having 2 sprites for the inventory item. One normal sprite, and the other to suggest that it's the currently held inventory item, whether that's a grayed out version or an outline of the inventory item, or whatever. Your best bet would be to probably use a View with 2 frames per Loop. The first frame being the normal graphic, while the second being the active graphic. Then you just change the inventory items graphic according to the inventory ID number and depending on what frame, and voila. Of course the Loop graphics would have to be in the proper order to match the inventory ID numbers.

Then using an extender function like so:

Code: ags

void normalGraphic(this InventoryItem*)
{
  if (this == null) return;
  if (this.ID > Game.GetLoopCountForView(VINVENTORY) return;
  ViewFrame *frame = Game.GetViewFrame(VINVENTORY, this.ID-1, 0);
  inventory[this.ID].Graphic = frame.Graphic;
}

void grayGraphic(this InventoryItem*)
{
  if (this == null) return;
  if (this.ID > Game.GetLoopCountForView(VINVENTORY) return;  
  ViewFrame *frame = Game.GetViewFrame(VINVENTORY, this.ID-1, 1);
  inventory[this.ID].Graphic = frame.Graphic;
}

It first checks if the inventory item is null, if it is it aborts the function. Then it checks if there is even enough Loops in the VINVENTORY view to accommodate for the current inventory ID, which also returns if there isn't.

Then you simply just call  iBanana.grayGraphic()  to change it to gray, or  iBanana.normalGraphic()  to change it back to normal.
It's just a suggestion. Do with it as you will.

That's crazy. I've honestly checked out that section more than once, but never really read past the dialog command list.
CJ's done an amazing job with the manual so far, but it definitely needs to be updated. It's not very user-friendly when it comes to searching up some stuff.

I haven't tested if it works yet, but I'm assuming it does.

It actually surprises the hell out of me why people are too stubborn to learn the new editor and drop the interaction editor. It has so many new and much nicer features.

It almost seems like it's disrespectful to the work CJ does to update AGS when I hear someone say they're still using an older version. But that's just the way I see it.

I like playing on peaceful though when I play online (lag makes it hard to kill monsters) so for me it's more like three dimensional pixel art!

I was told that the monsters on MP were fixed. Their attacking distance was decreased or something.
I'm tempted to try it.

Yeah, I've always wondered why this wasn't a feature. A windowed fullscreen capability.

Dualnames, you can't run stop within a dialog.

The only solution, like I mentioned above (other than using the blank dialog option with a stop, that Khris mentioned), would be to check the dialog of the number you pass through run-script. Because the Dialog_Request function is the Only way I know of that can stop a dialog.

Basically this:

Code: ags

// Dialog script file
@S  // Dialog startup entry point
return
@1
option-off 1
run-script 8
return
@2
option-off 2
run-script 8
return

8 would have to be the dialog number. It would probably be better to import the dialog_request into the Global script header so that you can do: dialog_request(dDialiog.ID);  instead of  run-script, in case you delete a dialog it would cause issues.

Then within your dialog request in the global script:

Code: ags

function dialog_request(int param) 
{
  if (param < Game.DialogCount)
  {
    int i = 1;
    bool stop;
    while (i <= dialog[param].OptionCount && !stop)
    {
      if (dialog[param].GetOptionState(i) == eOptionOn) stop = true;
      i++;
    }
    if (!stop) StopDialog();
  }
}

Of course you'd have to change any run-script commands you have.
Unless there is a way in the dialog_request to find out what dialog is currently running, but I can't seem to find anything in the manual. That would be a little better than passing the dialog number through run-script.

I have AGS pinned to my taskbar in Win7. I would love that when I right click on it, the recent list is actually populated with the correct name of the game instead of Game.agf. Is there a reason AGS is creating a Game.agf file instead of: Journy Of Iesir.agf?

I tested it by renaming a blank game's file and it didn't appear to run into any issues with loading, compiling or running the game.

Edit: Never mind about that last line. It appears that AGS will create a Game.agf file if the other is renamed. Obviously this would have to be changed if there aren't any issues with having a game file not named Game.agf.