Messages

This begs the question why you are putting two characters in the same spot to begin with.

I don't - they have minds of their own. I have 20-40 characters walking almost randomly, and they seem to develop minds of their own - always hunting out the narrowest part of any walkable area, then standing around in tight groups so nobody else can get past. Or that's what it looks like anyway. They do separate eventually. Maybe they're just friendly.
.
Anyhow, thanks for the suggestions. I've marked this thread "SOLVED" not because I can get the blighters to do what I want, but because I have enough insights now (thanks to you guys) that I don't feel quite as helpless as before.

I haven't checked. I'll have a look. Though it only seems to happen if they occupy the exact XY coordinate - they often brush past each other in a way that the transparent areas must surely overlap.

I'm not sure how it might play out, but have you tried using the Character.z property?

It's definitely an idea. Though I'd have to constantly check if other characters were close by - I often have five or ten characters trying to walk through the same point.

Character.z would be a great solution to a related problem that just arose: I have two crowds that walk "through" each other. It looks neat, except when they touch and stop. Character.z would be a good solution, but like a fool I designed the scene so the crowds are travelling exactly along the Y axis, and changing it now would be a huge job.

Ir's amazing how a very simple piece of code (two characters walking together) can quickly become very complicated. It takes two minutes to write and two weeks to bug-fix!

It looks like AGS has primitive collision detection built in all the time, that is, two characters cannot occupy the exact same xy location. Is that true?

Sometimes when characters are on or near the same point, first one is in front, then the other, then the first again, etc. So the costumes seem to flash as they rapidly change. Has anyone else seen this flashing? If so, any ideas on how to avoid it?

Thanks, I'll try that!

Edit: I tried it, and it works, but being random, the characters kind of walk in circles, stop frequently, and backtrack all the time. The more that I try to add direction to them, the more I have problems with getting trapped against walls or in corners, or stopping every second while I assess their direction.

Another edit: After another few hours, I think I've cracked it. It was a question of trial and error, changing all the variables, trying new subroutines, until it more or less works. The characters now wander around smnmoothly, as if they have a life of their own, and it's fun to watch them. They still get confused and sometimes clump together, but it's not a big problem as most of them eventually separate again. 

The key to making it work was to rely on WalkStraight. So thanks, Creator! Your advice was much appreciated.

This is a problem that can be masked by using anti-glide mode, but that only hides the underlying problem, and makes for jerky uneven movement. I'd appreciate any ideas for solving the underlying problem:

(a) How to cancel 'AddWaypoint' without using 'StopMoving'

(b) Any other suggestions for what I'm doing wrong?

I have thirty characters walking randomly across the screen. I found that using "Walk" caused everything to slow down (due to path finding) so instead I use "AddWaypoint" and every two seconds I check if a character is on a walkable area. This runs much faster, but sometimes (maybe one time in twenty) the character slides instead of walking. The slide lasts for two seconds until the next walk update, then they walk normally again.

Code: ags

		int dx = 40; if(GetGlobalInt(n + 100) !=1) dx = -40;	// go right, or go left
		int x = character[n].x + dx;
		int y = character[n].y -10 + Random(20);	// random element to avoid narrow lines
		
		//--------------------------------------------- aim for a walkable area --------------------------------------------		
		cFloorfinder.x = x;	cFloorfinder.y = y;	// place invisible "floor finder" character  there
		cFloorfinder.PlaceOnWalkableArea();	// find the nearest floor
		character[n].StopMoving();	// Needed to avoid crash from ever increasing number of Waypoints. 
		character[n].AddWaypoint(cFloorfinder.x, cFloorfinder.y);	// walk toward the new target

Even when the character walk properly there is a noticeable pause (just a couple of frames) at the 'StopMoving' command. That isn't nice, but I can probably live with it. The real problem is with not using the walk animation. "Antiglide" can stop the character at these points, but that causes more uneven walking.

Any ideas?

Thanks

-Importing with the "palette index 0" ... to not have any transparencies on a sprite

I wasn't aware that people used the feature in this way.

I've used that for ages.

Me too. (OK, "ages" for me is only a few weeks). "No transparency" is a common need when creating buttons (for example).

Thanks. If I can access the smoothing variable to disable it, then I guess that I could use it to trigger an alert when the game is played? Like "you clicked on X but for technical reasons..."

if the anti-aliasing was always doing this then it would pretty much render the feature useless ... unless most of the time people use sprites with well-defined edges...

Or mid-range backgrounds? The "dark" edge is often a grey of 50 percent brightness.

Maybe I should redesign my game along the lines of the Cramp Twins)

you can override it by setting "game.disable_antialiasing = 1;"  in the game_start script.

So the user would tick the box but nothing would happen?

Sorry, yes, I meant smoothing. It's good news if this has been fixed in 3.0 - thanks.  However, It's important to me that my game works in Linux, so I'll have to stick with 2.72 for the foreseeable future.

I guess I'll need to disable smoothing and blur the faces to compensate (so eyes and mouths don't disappear when scaled). Is there a way for me to disable the smoothing option in the standalone setup program so users don't click on it?

Eleven hours later...

I see I am not alone in noticing this: over a year ago, Adamski described the same problem.

Adamski is a lot smarter than me (he even has "moderator" in his title) and yet nobody replied to his question. May I conclude that this problem is intractible? Perhaps even (whispered voice) a bug?

This picture should explain my problem:


I am using 16 bit color. I realise that 32 bit color is needed for edge antialiasing, but I only need to antialias faces. All my characters have white edges and most of the backgrounds are white, so I don't care if the edges are jaggy. But where the heck are these dark artefacts coming from? There are no dark colors anywhere near the edges of the sprites, and the transparent color is pink. I've even added two pixels of white around the sprite, and the scaled screenshot is pretty close to 100 percent sprite size. But still the dark lines appear! What am I doing wrong?

You can also set x and y coordinates as parameters to have your player start offscreen and walk on if you so desire.

You mean ego can start off a floor and walk onto the nearest one? I thought the only way to get to a floor was to jump to the nearest one. Or do you mean using eAnywhere to force them along a scripted path?

PS thanks for the quick response. Is this the fastest forum on earth?

I know this has to be blindingly obvious. but I've searched for enter/leave/add/delete/remove/and all the other terms I can think of, in both the manual and the forums, and I'm stumped. How to I add a non player character to a room where they did not start? How do I remove a non player character?

My immediate need is for a very large scrolling text box, and after finding that the credits module doesn't compile in 2.72, the credits plugin doesn't work in Linux, and the scrolling module needs a later version, it seemed like the simplest thing to do is write the text on a bitmap and add it as a character. But I searched for "add character" or "character.delete" in vain. I'm sure there's something very simple that I'm missing here.

EDIT: after posting this I found a reference to "character.changeroom" - is that the answer? Maybe my problem is I'm too bloodthirsty. I assumed that I had the right to create and destroy characters at will (isn't the whole point of a game to satisfy one's god-complex?) But it looks like characters have to be treated with respect. Maybe I shouldn't be applying the meat cleaver every time I want some personal space, maybe I just need to suggest the character leaves when they are not wanted.

If you knew before hand that you had to have 140 rooms with some of the script being exactly the same of signicantly so, then you could create a template room and save it as _blank.crm.  Then whenever you create a new room it will be created with all the interactions, code, etc that is in the template.

Hindsight is a wonderful thing. Thanks - that looks like the elusive "master room" idea I was looking for, or close enough. And thanks to all the others who made suggestions.

Just to tie up the loose ends, I've been reviewing the situation (cue Fagin music) and have decided to cut the Gordian knot. I'm recreating the 140 room game with only the most essential 80 rooms, and I'm removing all non-essential code in favor of using the tried and tested default AGS methods. I figure that for me, a very amateur programmer, the time I spend on customizing code (then bugfixing it later) would be better spent on the game story itself.

surely the sensible thing would be to try it in one or two rooms until you're sure it works, THEN add it to the other 138?

Sensible? That's a technical word I'm not familiar with.

being too ambitious - not in the overall scope of the project, but in trying to do everthing at once. Pick a room, work on it...

Yes, I've been thinking about the ambition thing a lot lately, though not in that exact way. But first, in my whining defense, I did have the code working perfectly in two rooms first, or so I thought. But the problems only become apparent when I combine rooms, because every room will add something new and unexpected. Also, the "everything at once" method worked fine in Sludge, because it isn't room based. You could easily begin with hundreds of  rooms in a simple state, then globally add more and more features. With Sludge uit's easy to get the big structures right before focusing on individual rooms, in AGS it's the other way around.

But I'm rambling. If you'll forgive me navel gazing for a while, ambition is the key. My strength (I think) is ambition, in that I have a clear idea of a very large, achievable, unique, and interesting final product. But my weakness is in trying to create the greatest code, the greatest art, and the greatest puzzles. I'm not superman! To achieve the core objective (a very large game packed with seriously interesting stuff) I need to spend more time on what I'm good at, and less time on what other people do better.

I am starting to think that instead of "polishing" the AGS code to get the exact look I want, I should instead just use the default code and methods, add my own graphics, and spend more time on the story. So I may well rip out many of the troublesome code, remove the redundant scenes and redesign the game in a way that it might actually be finished on schedule.

This is all one big learning curve! Thanks for your timely advice. I don't know how you do it and still have a regular life.

You might be able to fake it if you disable the 'Fade In/Out' transition and script it in

Eureka! That's what I wanted. At least, that will solve my immediate problem, involving walking into the room. Thanks!

Why do you need to change the function call each time?

I'm probably not using the right terminology. But it seems that whenever I make a change to the game I get an error message, and solving it means adding another 140 calls.

To illustrate, this is my current task. Please note that this is for historical interst only. I've now added all the code heer so have no wish to go back and change it (unless there's a dramatically simpler solution). I'm making making ego walk in and out of exits using three XY coordinates for each journey (ie. ego walks off the floor, through a gate, then turns and walk out of sight). In my previous game I had various coordinates for each exit, so I copied these into the ""before fade in" interaction for each room. That was fair enough - the numbers were different for each room, so it made sense to put them in that place. After that I realised that I would need to call a function from each room, to add ego and read those exit numbers. That was the first time I added the identical function call to every room.

Foolishly I added it BEFORE setting the exit points, so that didn't work. So once again I had to add another function call to every room - this time after the exit points were set. But that didin't work either, because AGS won't let ego walk anywhere before the fade in.  So again, for the third time, I added another function call to the "after fade in" interaction for each room.

Add the fact that I often have to make minor changes to all the background images (e.g. to add extra space to walk below the level of the screen), or change all the floors (to remove secondary floors - these were causing problems if ego accidentally jumped to the wrong floor), or change all the hotspots, etc., etc., and I seem to spend all my time opening ten or twenty or a hundred rooms at a time to do stuff that previously I would have changed asll at once in a text file using search and replace.

Eventually I will just get used to thinking in a different way. Sorry to keep making the comparison with Sludge, but with Sludge there is no built-in "room" and no pre-compiled graphics, so changing anything is as simple as doing a global search and replace in a script. It's a real culture shock to find that the final script is not directly accessible as a text file.

I must emphasize that although this is a big complaint, I still prefer the AGS room based metaphor. The fact that Sludge has no built in rooms caused huge headaches when something complicated was supposed to end when a room ended. In AGS the rooms are cleanly separated. I guess that some restriction on cross-room coding is inevitable.

Still, if there is a "wish list" section this is mine: ideally, being able to export or import all the rooms as a big text files (or at least many small text files), and allowing interaction events to be added from the script. Failing that, it would be extremely helpful to have all the interaction events accessible to "on_event" and not just a select few as now.

Of course you would still have to put a function call everywhere you want the code

That's my whole problem! I have to add the exact same function call into the exact same place in 140 rooms.

The process is even simpler if you're wanting to execute this code as soon as the player enters/leaves the room.

EDIT:

Thanks for the suggestion, but it seems my initial guess was right. AGS 2.7 is very limited in what it will let you script - most things have to be tediously added by clicking the same buttons in every room, again and again and again. Man, this is depressing.

To clarify, if I understand the manual, on-event only allows for code being run before the "before fade in" event. It does not allow for code being run immediately after the "before fade in" event. It does not allow code immediately before the "after fade in" event. It does not allow code immediately after the "after fade in" event. The list goes on and on. Every day I need to make a change like this it's "here we go again, time to do the exact same thing one hundred and forty times."

I am a great fan of AGS, even allowing for this, but this limitation appears to suck. In a script-based engine I would simply open a folder full of rooms and do a global search and replace. Or if there was a "master room" I would simply edit that. The whole process should take about thirty seconds. But instead it takes about an hour to add or modify a single function call - open each room, click on interactions, click on the interaction I want, click on the list of choices, click on "run script," paste the function call, click on OK, click on OK again, do CTRL_R to save the room, click on the list of rooms, select the next room, and repeat, one hundred and forty times. That takes about forty minutes, then another twenty minutes to rub my sore wrist and work up the enthusiasm for the next mind-numbing task.

I know I have no right to complain. Nobody is forcing me to use AGS, and nobody is asking for money, and everyone is so generous in offering help. But AGS is so wonderful in other areas that this is like driving a fast car into quicksand.

My game has 140 rooms. I often want to call identical code from each room. Each time I have to open each room and press several buttons to get to the interaction I want, then add the code, press more buttons, save the room again... It takes ages.

Is there any "master room" that I can change that will automatically change all the others? Or some way to treat the rooms as text files so I can add an interaction using global search and replace? Or some other way to avoid the mind-numbing tedium of repeating the same actions 140 times?