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 ... 212
Thanks. That does something... but sadly it's not the solution to my problem. And with a game with 150 rooms it takes the piss a bit...

How is it not the solution? You should end up with a set of text files with all the property values (though you might just want to write it all to one file instead of 150 of them), and then you can paste the strings into the translation_hack() function CW suggested to have them included in the translation.

To loop through all the rooms automatically, you could try something like this. It's a little convoluted because you have to make sure you don't try to go to a room that doesn't exist (which will crash), and there's no way from within AGS to know whether it does in advance. If you've just created the rooms sequentially and never deleted any it's quite simple, but in general the best approach is probably to write a little function that tells you whether a room is valid:

Code: Adventure Game Studio
  1. #define MAX_ROOM 150 // or whatever the highest room number is
  3. bool isValidRoom(int i)
  4. {
  5.   // Check whether the given room is valid. Depends on how you have your rooms set up.
  6.   // For example:
  7.   if(i>=1 && i <= 45) return true;
  8.   if(i>=50 && i <=102) return true;
  9.   if(i>=300 && i <=345) return true;
  10.   return false;
  11. }
  13. int nextValidRoom()
  14. {
  15.   int i = player.Room+1;
  16.   while(!isValidRoom(i))
  17.   {
  18.     i++;
  19.     if(i>MAX_ROOM) return -1;
  20.   }
  21.   return i;
  22. }
  24. function on_event(EventType event, int data)
  25. {
  26.   if(event == eEventEnterRoomBeforeFadein)
  27.   {
  28.     // CW's code
  29.     int nextRoom = nextValidRoom();
  30.     if(nextRoom>0) player.ChangeRoom(nextRoom);
  31.   }
  32. }

"Hotspoty" is a typo. "my_property" is the name of your custom property. (If you have multiple, you'd want to read each one and write it to the file.)

You can put the code in an on_event() function in the global script (see manual for predefined global script functions), to run when the event is eEventEnterRoomBeforeFadein:

Code: Adventure Game Studio
  1. function on_event(EventType event, int data)
  2. {
  3.   if(event == eEventEnterRoomBeforeFadein)
  4.   {
  5.     // CW's code
  6.   }
  7. }

Now whenever you visit a room, all its hotspots' properties are written to the file. Looping through the rooms automatically is a little tricky, so it's probably easier to just to that manually, maybe using the debug feature to jump to each room.

If you can't work out any other way, you could write a module script that loops through each room and each hotspot[] array and prints all the property values to a text file. That way it won't take you a week to find them all, at least!

Critics' Lounge / Re: AGS awards ceremony client test
« on: 12 Feb 2016, 08:07 »
Yeah, it runs fine for me too (WEI 5.3, limited by harddrive speed), but there's a lot of stuff going on in the real client, so I'm not sure how meaningful this test is in isolation. (I also wonder about things like whether it makes a difference when you have 50+ DIFFERENT characters, not just copies of the same one, so having to access different parts of the sprite cache... No way to tell without actually trying it.) Still, cool to see that in a simple game you can indeed have that many characters on screen simultaneously.

Several options, but the easiest is to write a helper function:

Code: Adventure Game Studio
  1. bool isKey(this InventoryItem*)
  2. {
  3.   if(this == inventory[2] || this == inventory[7] || ...)
  4.     return true;
  5.   else
  6.     return false;
  7. }

You can put this in the global script or its own script module, importing it in the corresponding header file:

Code: Adventure Game Studio
  1. import bool isKey(this InventoryItem*);

And now you can just write:

Code: Adventure Game Studio
  1.   if(player.ActiveInventory.isKey())
  2.     Display("say what");

Just for the record, real-world concerns concerns make it impossible for me to take on any such heavy responsibility, even if I thought I'd be a good person for the job (which I don't). I'm actually trying to step down my AGS involvement, and have asked the other mods to keep an eye on the boards I moderate, as I may not always be around.

IMO, anyone who wants to lead the direction of AGS development would need to be involved hands-on in that development.

Yeah, this has been my position all along. I'm not against paying someone to work on AGS in principle – I'd be happy to chip in if there was a credible plan/arrangement set up – but lack of money has not been the limiting factor holding AGS development back. Lack of motivated, knowledgeable developers, organization and decisiveness has been. This list:

1) What do we all want? (features list)
2) How to do it, so the cost? (tech side)
3) Who for the job?

... is essentially the same sticking points we have talked about since at least 2012. Further discussion, opinions and ideas are not getting us anywhere. For anything to happen, someone has to step up and just do it (whatever it is).

There's a "director" who handles the whole show, deciding what goes on the screen, what music to play, etc. In all previous years that's been the developer (Dualnames, and then me last year – with Dualnames stepping in when I needed a break).

I've PM'd you about the technical issues. I would advice against two versions: because a lot of resources and some of the code is tied to resolution, and AGS doesn't have good source-control support so it'd be very hard to keep code changes in sync, I think it would make development and debugging a bit of a nightmare.

The bots in the balcony are Daft Punk acting as DJs. They don't do anything except nod their heads when there's music playing. (They're pretty much a joke from a few years back that no one ever bothered to take out again.) People on text-only IRC don't show up in the audience, but if they're granted voice or host/admin status they appear on stage dressed as Indy (one request from last year was to make them appear as different characters, not all the same).

If I can just throw some feature requests out as a regular AGSer, the sound system could use some improvements:

-better applause clips and fix applause logic
-better volume controls: currently the volume of fanfares and applause can't be adjusted independently
-allow people to choose their own music (overriding the host's choice) when outside the actual ceremony

Good luck to you on this. I do think before you set out there are a few things you might want to clear up:

1280 x 720 background of an auditorium with a stage, ample standing room and a large main screen behind the stage.

Did you check out the asset pack I provided with last year's build? We have a 1280x960 version of the existing background.

Some good reasons why it's scaled down are:

1. For consistency with the characters, since most of them are low-resolution. I'm not sure you gain much by running in 1280x720 when most of the characters are 320x200.
2. For performance. Because of engine limitations, you have to run the awards client with DirectDraw (i.e. in software), and it may run slow if you display lots of sprites in high resolution. This is something you should definitely test properly before switching to higher res.

You argued in the other thread that higher resolution would make it less crowded in the audience. That's not automatically true: It depends solely on the size of the characters relative to the resolution. To get more space, you'll have to draw a background where the characters are smaller. With the dimensions you propose (100 px height in 1280x720 resolution), that will be the case – they'll be about 88% the height of Ben Jordan in the current version, but of course the tradeoff is that everything looks smaller/farther away, as in this mockup (Nelly and Ben are both ~100px tall):

Whether this is preferable is debatable. Personally I think the people on stage become a bit remote, though it's not too bad. However, if we need much more space in audience, I would instead suggest making the background scrolling (left-right). I feel like the wider aspect ratio shown here isn't ideal, given that part of the height is taken up by the chat window; I think scrolling would make more sense.

Switching to higher resolution also means you'll have to replace every graphics resource (buttons/UI, titles, some of the fonts...), redo the intro screen, and probably fix the code in a number of places. Oh, and since AGS limits character scaling to 200% max, you'll have to upscale low-resolution characters outside of AGS and reimport them. All in all, it's a significant effort.

Oh, and another important point! The client runs in a special build of AGS 3.3.3: it requires late_repeatedly_execute_always(), which has only been included in the latest 3.3.5 build – AFAIK not in any 3.4 build. I don't believe 3.3 supports 1280x720 as a resolution; the closest is 1280x768.

On a personal note, I quite like the current background and the traditional look of the ceremony hall, like an historic theater, and I think it would be a shame if a new background lost that classy charm.

Music is needed for the gathering before the show, or when the host spills their drink. Anyone is free to contribute music in any style they wish, but I would prefer to use a handful of tracks all in the same style. My wish list is 3 or more muzak (relaxing, instrumental) tracks with melodies inspired by great adventure games.

We do already have a number of music tracks for these bits, but sure, could always use more.

SpritesWe will probably re-use all of last year's sprites, but it would be good to add a few new ones. A full walk cycle of your sprite is needed with four directions. Character height should be close to 100px.

Because of work I did last year, characters can be any size (though in practice I pre-downscaled very large ones to improve performance), and will be scaled appropriately in-game. It's not feasible in practice to require all provided characters to be the same size.

Oh, and I think I know what you were talking about with trophies. There was one in the offline game version of the ceremony, but it's never been used in the online client (partly, I think, since the graphic style doesn't quite fit):

If someone creates new trophy sprites, it shouldn't be too hard to somehow integrate them into the ceremony.

As a piece of general advice, if you haven't already I'd highly recommend starting out by familiarizing yourself with the code and testing that you can compile and run it, and actually host/guest over IRC.

The game you're thinking of is No-Action Jackson.

Others that might fit the description (to a greater or lesser extent):
Maniac Mansion Mania + other MM/DOTT fangames (obviously)
Dr. Lutz and the Time Travel Machine
Murder in a Wheel
The Bum
Nancy the Happy Whore
Once Upon a Crime
Day of the Monkey (Visionaire)

Good going Mods!

If no one more familiar with the awards steps forward, I will do my best to update the scripts of the latest version of the awards ceremony client source that's available.

That would be this:
However, because of limitations set by some of the people who donated character avatars, the public version has been stripped of some of those resources. I'll share the "uncensored" version with whoever takes over the development.
I could probably - in a pinch - do the simple bit of just updating the nominees for the current year, but unfortunately I don't have the time to tackle the bigger feature requests, so if you or anyone wants to have a go at that, by all means go ahead. It's also necessary to have some basic IRC knowledge and to set up (and protect) the appropriate channels on the AGS IRC server; I might have some notes on that from last year that could come in handy.

Someone should make new backgrounds and tropies. We can re-use the backgrounds if we have to but IMO we should not re-use the trophies.

I'm not sure what this is referring to.

General Discussion / Re: Star wars VII, the force awakens
« on: 01 Feb 2016, 19:27 »
If being able to understand the non-action film parts of all previous Star Wars films makes me intellectually superior, then yeah, I'm intellectually superior.

And everyone who doesn't get it should have ruined a different series.

The Star Wars movies are not exactly challenging material. Your assumption that hoi polloi are too stupid to grasp their intricate complexity and great profundity, or that any subjective flaws in the new movie is because the filmmakers couldn't grasp the originals is... well, let's just say entirely consistent with your attitude on any subject.

General Discussion / Re: Star wars VII, the force awakens
« on: 01 Feb 2016, 18:39 »
Haha, yeah, let's be all intellectually superior over and decry the commercialization of fucking STAR WARS! (laugh)(roll)

General Discussion / Re: I give up
« on: 01 Feb 2016, 17:02 »
What I was saying in the post I deleted, is that I was continuously chose wrong solutions to existing problems. I wasted my time, and I wasted the time of those who expected results.

Many people said I do "hard work" but it was hard work beating a wall with my head, while I should have made a door.

I am so disturbed by my incapability, that I feel uncertain to start any more projects now. I am literally afraid to write code.

I know I've told you this before, but making mistakes is an inevitable consequence of challenging yourself and trying something. It doesn't make you a failure, or the effort meaningless. If you haven't been able to "fix" AGS, eh, it'll be be all right, and we certainly appreciate the attempt.

Engine Development / Re: AGS engine Mac OS X port
« on: 01 Feb 2016, 16:36 »
It will always be open source. We literally *can't* make it closed source as AGS is open source - we'd be breaking the terms of agreement!

Sorry to be a stickler, but this is not actually correct, since the license that AGS uses, The Artistic License 2.0, allows the distribution of modified versions without the source under certain conditions. The most relevant case is as long as you ensure that it does not interfere with installation of the standard version (which it shouldn't) and you give it a name that is different from the standard version (and I believe for this purpose, it's enough that you're distributing your games under their own titles, not just as "AGS").

Besides, we don't want to :)


Editor Development / Re: Strings Again
« on: 01 Feb 2016, 10:34 »
C, C++ and C# are not the only major C-like languages, monkey. For starters, you have Java, PHP, Perl, Objective C, JavaScript...

In C, attempting to compare strings with == is a common mistake. Java uses reference-comparison, but also has a string pool, which means that '==' will work as a string comparison under some circumstances (which can make bugs even harder to find). PHP lets you use the equals operators to do string comparisons; in this case (null == "") is true, but (null === "") is false (a lot of other == comparisons you wouldn't expect also come out true, and it's generally considered wrong to use it in most cases). I think JavaScript works more or less the same. Perl tries to convert the two values to ints, with potentially unpredictable results. Objective C uses reference comparison.

So in most of these languages, '==' is not the right way to do a string comparison.

Editor Development / Re: Strings Again
« on: 31 Jan 2016, 15:14 »
String comparison is tricky, because you need to be able to compare both objects (which can be null) and literals. If you let the '==' operator just do a simple pointer comparison (as it does for most other objects), you'll get counter-intuitive results where two strings with exactly the same content (possibly even two string literals, depending on the underlying implementation) may evaluate as unequal, which makes it more or less useless. (Your C# examples don't test this case, but if it avoids it, it is only be considerable complexity under the hood.)

If you just make '==' a shortcut for the string-comparison method a.equals(b) (as AGS does), it will choke if the first parameter is null. If you make this string-compare accept nulls in the argument, you'll now be in a situation where 'a == b' and 'b == a' will evaluate differently if b is null, which I would argue is very bad.

For these reasons, most C-like languages discourage use of '==' for string comparisons (though some simply treat null as an empty string); the decision to support it in AGS may not have been the best, but we're stuck with it now.

Adventure game or non-adventure? In either case it doesn't belong on this sub-forum.

Pages: [1] 2 3 ... 212