Show Posts

You can view here all posts made by this member. Note that you can only see posts made in areas to which you currently have access.

Messages - Snarky

Pages: [1] 2 3 ... 195
The Rumpus Room / Re: *Guess the Movie Title*
« on: Yesterday at 09:27 »
How very!

You can
@Snarky :
I managed to get the code working, but only in room script, not in global script. ive tested it with a display command on the is timer expired and it works! but still the GUI wont update even i put the codes at repeatedly execute always on the global script.

Ah, I see now what the problem is: slasher's code makes sure to restart the timer when it runs out, but it never starts it in the first place, so it never gets triggered.

With Khris's version, well, the error message is telling you exactly why it's not working: You can't "nest" functions, which means to put one function inside another function, and on line 8 you have the function ChangeHealth() inside of the function game_start(). You should put ChangeHealth() and GetHealth() outside of any other functions (right above game_start(), for example). I would also put the update of the label inside of ChangeHealth() so that you don't have to remember it every time.

Then you need to actually call ChangeHealth(). All in all, this should be your GlobalScript.asc code:

Code: Adventure Game Studio
  1. bool ChangeHealth(int amount)
  2. {
  3.   health += amount;
  4.   LabelHealth.Text=String.Format("%d",health);
  5.   return health > 0;
  6. }
  8. int GetHealth()
  9. {
  10.   return health;
  11. }
  13. function game_start()
  14. {
  15.   SetTimer(1,600);  // Start counting down to when we'll decrease the health
  16. }
  18. function repeatedly_execute()
  19. {
  20.   if(IsTimerExpired(1)) // ... it's time to decrease the health
  21.   {
  22.     ChangeHealth(-5);
  23.     if(GetHealth() > 0)  // ... we're still alive
  24.     {
  25.       SetTimer(1,600);  // just start counting again
  26.     }
  27.     else  // player has died
  28.     {
  29.       // ... whatever you do when dead
  30.     }
  31.   }
  32. }

See if you can try to actually understand this code, and why it's (hopefully) working while the earlier versions didn't.

The Rumpus Room / Re: *Guess the Movie Title*
« on: 28 Jun 2015, 23:44 »
Is there no communication in this forum? Have we deteriorated to the level of dumb beasts? (That's not the movie, BTW.)

quick reply and hopefully correct ;)

Looks correct to me (except for the indentation)! Nicely done!

If it were my code I'd make some nitpicky changes, but this should work fine.

thank you there Slasher!

I've tried the code, ran without error, but the text in GUI are not changed somehow after 15 seconds.

I've also tried to move

Code: Adventure Game Studio
  1. int health=100;

from the globalscript.ash to the globalscript.asc but it gave me error

Code: Adventure Game Studio
  1. GlobalScript.asc(28): Error (line 28): undefined symbol 'health'

I suppose i will have to set the condition in the same code brackets as above?

The "int health=100" should definitely go in GlobalScript.asc - this might possibly be why you're not seeing the label update. And it can't go inside of a function, because then it will disappear as soon as the function is over, and won't exist any more in the next loop.

I'm not sure about the error: could it be that you're putting "int health=100" below either obj_blue_Interact() or repeatedly_execute_always()? It needs to be above, so that the script knows about it before it gets to where you try to use it. Typically, variable definitions go at the top of the script, before any of the functions. But if you let us know what line 28 in your script is, that would make this much easier to answer.

The Rumpus Room / Re: *Guess the Movie Title*
« on: 27 Jun 2015, 01:21 »
Then how about this?

The Rumpus Room / Re: *Guess the Movie Title*
« on: 26 Jun 2015, 14:39 »
My friend Imdub says it might be Song of the Sea?

This is a good example of why proper code formatting is important. Check it out after reformatting:

Code: Adventure Game Studio
  1. function oCyborgeadUp_UseInv()
  2. {
  3.   if (cDoe.ActiveInventory == iHoe)
  4.   {
  5.     if (SkullDown > 0)
  6.     {
  7.       cDoe.Say("I need something bit longer");
  8.     }
  9.     else if (SkullDown == 0)
  10.     {
  11.       cDoe.Walk(266, 550, eBlock, eWalkableAreas);
  12.       Wait(20);
  13.       cDoe.Say("This is too short to grab on anything");
  14.       SkullDown = 1;
  15.     }
  16.   }
  17.   else if (cDoe.ActiveInventory == iHockeystick)
  18.   {
  19.     if (SkullDown == 2)
  20.     {
  21.       cDoe.Say("How can I find something little bit longer?");
  22.     }
  23.     else if (SkullDown != 2)
  24.     {
  25.       cDoe.Walk(266, 550, eBlock, eWalkableAreas);
  26.       Wait(20);
  27.       cDoe.Say("Just an inch or so and I could grab that chain");
  28.       SkullDown = 2;
  29.     }
  30.   }
  31.   else if (cDoe.ActiveInventory == iGrablinghook)
  32.   {
  33.     cDoe.Walk(266, 550, eBlock, eWalkableAreas);
  34.     Wait(20);
  35.     cDoe.Say("Ok let's grab that chain");
  36.     Wait(20);
  37.     cDoe.Say("It's working and something is coming down with that chain");
  38.     oChainUp.Visible = false;
  39.     oCyborgeadUp.Visible = false;
  40.     oChainDown.Visible = true;
  41.     oCyborgeadDwn.Visible = true;
  42.     SkullDown = 3;
  43.   }
  44.   else
  45.   {}
  46. }

It is now obvious that the brackets all match, so the error must be somewhere else. (Also, in general it would be helpful if you let us know where "line 72" is in the excerpt you posted, though it wouldn't have made a difference in this case.)


The key element of the pancake model is that when floors from above crash into the lower ones, they'll push them down (so the lower floors won't just start free-falling from a rest state).

Depends on how much energy is consumed at each step. If nearly all energy is lost with just enough to trigger the next floor, then the next floor would start from rest.

But then we're modeling the upper bound of the collapse time, not the lower bound, FFS! If we were trying to prove it couldn't take longer than a certain time, fine. But Wood specifically presents this as a model that makes only generous assumptions towards the "pancake" scenario, so that if this model fails, the pancake scenario must be wrong. Its utter unsuitability for this purpose, and the inconsistency between what she claims and how the model is designed, is what discredits her.

We can do this for every floor, or every 10 floors (thus different arrangements of billiard balls) which is synonymous with modelling the different scenarios of energy losses.

It's not, actually. Starting over from rest every 10 floors is not the same as losing 10% of the energy each floor.

Also, I believe the energy loss is more likely to be a constant term (or close to it), not proportional to the total kinetic energy. This would tend to make it increasingly insignificant as the collapse progressed and sped up.

The 9/11 commission report itself said the collapse took 10 seconds. Any other value in the vicinity of 10 seconds is at the lower end of the range of values. If you argue 100 seconds is a ridiculous time, then wouldn't it be fair to say 10 seconds is equally ridiculous? Nevertheless, this is what we see.

In context, the 9/11 commission's report was only giving a rough estimate, and should not be taken as an authoritative figure. I also find it hilarious that you would dismiss the whole official story, yet latch on to a single off-hand mention of this round-number estimate from the official report, just because it supports your pet theory.

No part of the 10-100 second range of collapse is a priori ridiculous. I believe that under suitable conditions, the collapse of a building as tall as the twin towers could take as little or as long as that. But I also think that in this particular case it's very implausible that tearing down one floor would consume nearly all the kinetic energy of the top 10-20 floors falling onto it (or indeed more than a very small part of it), so I would lean more towards the lower end of the scale.

I really have had it with this discussion, and won't be responding further.

There used to be a problem with very short clips (or maybe clips that had certain sizes, divisible by some particular number) not playing, though I don't remember if that was for MP3 or OGG files. Could you try it with a different (longer) sound clip?

There's also stuff to do with default volumes for different sound types/clips, though it really shouldn't come into play when you start a game from scratch. Still, might be worth ruling out by changing it to:

Code: Adventure Game Studio
  1. function spot1_Look()
  2. {
  3.     Display("I am about to play sound!");
  4.     AudioChannel* soundChannel = gold1.Play();
  5.     soundChannel.Volume = 100;
  6. }

If that doesn't work, we might have to look into drivers and so on. What's your OS and your AGS version?

And could you confirm that sound plays in other AGS games?

Yes, though of course in practice not all of the momentum is conserved within the collapsing building itself. At the impact with each floor, some of the energy is used to tear apart the structure (and in terms of momentum, it is transmitted down through the building and eventually into the ground). It is this factor (how much of the collapsing weight is absorbed by each floor before it fails) that will really determine the speed of collapse in a "pancake" scenario.


Billiard ball example

The billiard ball example is simply using billiard balls as timing devices, each starting at rest and then accelerating at free fall when triggered, like a relay race. Billiard balls are not interacting in this example; they are just timing devices. It is interesting to note that one billiard ball dropped from the top of the building takes about 10 seconds to hit the ground at free fall. Additional billiard balls are introduced to incorporate a resistance or hauling effect in the progression. Different arrangements of billiard balls are used to show different scenarios. The example serves to illustrate that the overall collapse (assuming it is possible) should have taken longer than 10 seconds. The example should not be confused with attempting to calculate an actual collapse time.

But if the billiard ball examples are to have any bearing on the argument at all, they must bear some relationship to the models in question. Wood's billiard ball examples don't. The "Case 2" model is said to be a way to estimate how long the collapse would (at least) take in the "pancake model" ("So, even though the mechanism to trigger the "pancaking" of each floor seems to elude us,  let's consider the time we would expect for such a collapse. To illustrate the timing for this domino effect, we will use a sequence of falling billiard balls, where each billiard ball triggers the release of the next billiard ball in the sequence by simply passing it in space.") The key element of the pancake model is that when floors from above crash into the lower ones, they'll push them down (so the lower floors won't just start free-falling from a rest state), but the Case 2 billiard ball simulation doesn't account for this, yet claims that "Thus, if anything, this means the calculated collapse times are more generous to the official story than they need to be."

It's not. It's a bizarre distraction (the model itself makes no sense) that fails to provide any information about the pancake scenario. Claiming that it does by itself demonstrates such incompetence that it's enough to discredit her completely: none of her models or calculations can be taken seriously.


1. The buildings fell too quickly

Obviously a progressively increasing number of floors have more mass than an single floor.  So as the collapse proceeds, the falling mass's velocity loss is proportionally smaller and smaller.

This is incorrect. Conservation of momentum says that as two masses impact and combine (inelastic collision), then the resulting velocity decreases. This means the collapse could not have been faster than free fall speed.

Uh, none of that contradicts what CW said. And of course the collapse could not have been faster than free-fall speed. That's why people keep returning to the videos where it's clear that it's not, because the debris is falling much quicker than the collapse.

My argument is that resistance in the progression (assuming there's enough energy to keep it going) should slow things down and produce an overall collapse time somewhere between 10 and 100 seconds depending on how much energy is lost along the way.

Fine. Of course,"between 10 and 100 seconds" is such a broad range as to be nearly meaningless. It clearly covers the actual collapse time of the buildings, in any case.

The towers did indeed fall near free fall speed. Does this make sense?

The best estimates for the time the collapse took seem to be somewhere between 15 and slightly above 20 seconds (it's hard to tell exactly because it was obscured by dust clouds), while free-fall is less than 10 seconds. That strikes me as significantly slower than free-fall speed.

In other words, your claim #1 has not been established.

The demolition expert you mention, Brent Blanchard, focusses on the implausibility of a controlled demolition by conventional means (e.g. dynamite). This is fine, but he instead supports the progressive gravity-driven collapse model and does not question the implausibility of this. In reality, under the gravity-driven "pancake" model, there wouldn't be enough energy to pulverise floors and also keep the collapse going. *


Well, now we're into more of the crux of the matter, but also beyond what simple high school physics can easily answer. Still, I don't know about "pulverize", but it seems highly implausible to me that the force of the top 10-20 floors falling down one floor would not be enough to cause the next floor down (and related building structure) to collapse. By your own numbers, that would be more than 10,000 tons just of steel, falling almost 4 meters. I don't think any building is designed to withstand that. And if it did collapse, then all of that falling another floor down should also cause the next floor to collapse, and so on. (Some of the mass is lost as dust and debris falling off the side, but more is almost certainly picked up from the progressively collapsing floors.)

(Oh, and as for the "pulverizing," keep in mind that the smashing up of the floors did not all happen in one go. For floors below the initial structural failure, you had: 1. being struck by the building from above, leading to collapse; 2. after collapsing, striking the floor(s) below during the rest of the building collapse; 3. striking the ground; 4. being struck again from above by the rest of the building collapsing on top.)

And honestly, that's as far as I'm willing to delve into this rabbit hole. The bits of the argument I've bothered to look into collapse like... a house of cards, let's say, and that gives me no confidence in the other claims.

So quickly about the other points:

1. The amount of debris: Your calculations could be wrong (is 1.5 a reasonable bulking factor? unknown), the photos could be misleading (from certain other angles the pile looks much higher), and/or it may have fallen elsewhere (i.e. more towards the other side of the building).
2. The seismic record: Basically, I think you need to be a trained seismologist with knowledge of the local conditions to properly interpret this data. AFAICT, no person fitting that description has come forward saying there's anything fishy about it.

I'm done.

I've finally got around to sorting out the credits, licensing, documentation, etc., so here's the source code and graphics pack for the AGS Awards client. Thanks (one final time) to all of you who contributed stuff, helped out and put up with my nagging!

I wasn't able to credit beta testers (I'd have to go through the logs to see who were there, and map from IRC nicks to AGS usernames...), but I am very grateful.

- Edit2: OK, the download is back up!

That sounds right to me, so I merged this into the completed game thread.



I thought this was an interesting look at some of the impressive things that can be done with neural networks, while also showing some of its limitations:

(Keeping in mind, of course, that in each of these examples the algorithms and settings have been tweaked by humans to give the best results, and the pictures selected as the best illustrations.)

Depending on how you animate the background, you might be able to move those commands to a repeatedly_execute_always() script. (IIRC, even though AGS doesn't provide it for you, you can place a function by that name in the room script and it will run automatically.) You can't run any blocking commands from the script, but you should be able to reposition the background, or manually change animation frames.

The Rumpus Room / Re: *Guess the Movie Title*
« on: 18 Jun 2015, 21:25 »
I don't know, seems like Quintaros has forgotten about this thread, so I declare selmiak correct.

Hi Woffle, sorry for the delay in responding. I've had a look at SSH's Description module, and it looks to me like it supports what you want "out of the box."

The relevant setting is, I believe, Description.CropGUIToo, which tells the module to only make the GUI as big as you need to display the current text.

Using the module code as-is, something like this should work to set it up (untested):

-Create a GUI with the background you want to use. Make it the max size of the hovertext you would ever want to display.
-Put a Label on the GUI, similarly sized. Call it, for example, lblDescription

Now edit the game_start() function in your global script, adding the initialization of the module:

Code: Adventure Game Studio
  1. function game_start() // called when the game starts, before the first room is loaded
  2. {
  3.   Description.GUIMode(lblDescription); // <--- This is what makes it use the GUI you created. Use the name of your label here
  4.   Description.CropGUIToo = true; // <--- And this should make it resize the GUI to fit the text
  6.   // The rest of these settings can be whatever you like...
  7.   Description.Location = eDescLocationSticky;
  8.   Description.VerbMode = eDescVerbModeNever;
  9.   Description.OffsetX = 10;
  10.   Description.OffsetY = 5;
  11.   // (more settings here...)
  12. }

Hope that helps!

Beginners' Technical Questions / Re: More regions..
« on: 16 Jun 2015, 12:20 »
OK, great. I see a few problems:

-The direct cause of the crash is, I think, that you haven't initialized the number[] array by calling initNumbers(); this is what I asked you in the last post
-You've mixed different versions of the snippets we've given you, with duplication and unused code. This can be simplified
-You're using a different method to roll the die, so you don't need the Random() call.
-You really don't want (or need!) to write six different cases, one for each number on the die. It's very simple to have the same code for all of them, and that's part of what the snippets we gave you were for
-You really need to learn how to indent. By not doing it consistently you create a lot of confusion and possibility of bugs

Here's a cleaned-up, hopefully fixed version of the code:

Code: Adventure Game Studio
  1. //top of room script
  3. bool roll=false;
  4. bool throw=true;    // You're never actually setting this value to anything other than true, so it's redundant
  6. #define SQUARE_COUNT 28
  7. int currentSquare;
  8. int squareX[SQUARE_COUNT];
  9. int squareY[SQUARE_COUNT];
  10. String numberString[7];
  12. void initNumbers()
  13. {
  14.   numberString[0] = "zero";    
  15.   numberString[1] = "one";
  16.   numberString[2] = "two";
  17.   numberString[3] = "three";
  18.   numberString[4] = "four";
  19.   numberString[5] = "five";
  20.   numberString[6] = "six";
  21. }
  23. void initBoard()
  24. {
  25.   // From square 1
  27.   squareX[0] = 50; squareY[0] = 470;
  28.   squareX[1] = 50; squareY[1] = 379;
  29.   squareX[2] = 136; squareY[2]=368;
  30.   squareX[3] = 50; squareY[3] = 268;
  31.   squareX[4] = 50; squareY[4] = 173;
  32.   squareX[5] = 136; squareY[5] = 173;
  33.   squareX[6] = 225; squareY[6] = 173;
  34.   squareX[7] = 225; squareY[7] = 255;
  35.   squareX[8] = 314; squareY[8] = 173;
  36.   squareX[9] = 396; squareY[9] = 173;
  37.   squareX[10] = 485; squareY[10] = 173;
  38.   squareX[11] = 575; squareY[11] = 173;
  39.   squareX[12] = 575; squareY[12] = 237;
  40.   squareX[13] = 658; squareY[13] = 173;
  41.   squareX[14] = 744; squareY[14] = 173;
  42.   squareX[15] = 744; squareY[15] = 265;
  43.   squareX[16] = 744; squareY[16] = 355;
  44.   squareX[17] = 744; squareY[17] = 254;
  45.   squareX[18] = 744; squareY[18] = 371;
  46.   squareX[19] = 672; squareY[19] = 382;
  47.   squareX[20] = 678; squareY[20] = 457;
  48.   squareX[21] = 744; squareY[21] = 457;
  49.   squareX[22] = 586; squareY[22] = 457;
  50.   squareX[23] = 494; squareY[23] = 457;
  51.   squareX[24] = 494; squareY[24] = 438;
  52.   squareX[25] = 415; squareY[25] = 457;
  53.   squareX[26] = 322; squareY[26] = 457;
  54.   squareX[27] = 322; squareY[27] = 376;
  55.   squareX[28] = 278; squareY[28] = 376;
  56. }
  58. function room_Load()
  59. {
  60.   initBoard();        // ADDED!
  61.   initNumbers();      // ADDED!
  62.   currentSquare=0;    // CHANGED!
  63.   gStatusline.Clickable=false;
  64.   cGandolf.Clickable=false;
  65.   cGandolf.Baseline=0;
  66.   cHobbit.Loop=3;
  67.   game.speech_text_align=eAlignLeft;
  68.   oDice.SetView(6);
  69.   oDice.Animate(0, 4, eRepeat, eNoBlock);
  70. }
  72. void movePlayer(int squaresToMove)
  73. {
  74.   currentSquare = (currentSquare + squaresToMove) % SQUARE_COUNT;
  75.   cHobbit.Walk(squareX[currentSquare],squareY[currentSquare]);
  76. }
  78. function oTumbler_Interact()
  79. {
  80.   if(roll==false && throw==true)
  81.   {
  82.     oTumbler.SetView(6);
  83.     oTumbler.Animate(1, 1, eRepeat, eNoBlock);
  84.     oDice.SetView(6);
  85.     oDice.Animate(0, 1, eRepeat, eNoBlock);
  86.     roll=true;
  87.   }
  88.   else if(roll==true && throw==true)
  89.   {
  90.     oDice.StopAnimating();
  91.     oTumbler.StopAnimating();
  92.     Wait(10);
  93.     oTumbler.Move(oTumbler.X, oTumbler.Y-40, 2, eBlock, eAnywhere);
  94.     Wait(20);
  96.     cGandolf.SayAt(cGandolf.x+9, cGandolf.y - 100, 500, String.Format("You have rolled a %s.", numberString[oDice.Frame + 1]));
  97.     oTumbler.Move(oTumbler.X, oTumbler.Y+40, 2, eBlock, eAnywhere);
  98.     movePlayer(oDice.Frame + 1);
  99.   }
  100. }

I also feel the need to point out that if this is meant to be a Hobbit game, the name of the wizard is Gandalf, not Gandolf.

Pages: [1] 2 3 ... 195