Messages

Sorry, but I have to bump this.

Terran, I didn't re-checked your Beginners' FAQ until recently, and found that some of the the infos are still outdated, so you probably should check this thread and incorporate some of the changes.

Nope, for some reasons they're different. When you test a game the editor was (intentionally) freezed, if you just run the executable directly from the compiled folder the editor won't be freezed (I think).

The ^T feature is a bit fuzzy, it may cause some problems in some computers, if you never have any problem with your computer you can continue using it happily, but if it exhibits problems in your computer (for example, my WIN95 computer freezed once out of 4 times usage of that feature), it's advisible you don't use it.

Well, since those scripts are in the interface_click() function (I suppose, and they should be there), I don't think the CentreGUI() and GUIOn() lines are necessary (as they should be called when you call up the GUI's already.
For the button not responding part, had you checked the properties of them and are sure that they're set to receive clicks? (Left click set to 'Run script')

It can be anything, as long as it can show that you're indeed making progress on your game.

But if you really don't want your ideas be stolen copied by others I recommend that you don't start anything in the Games in Production forum, as that forum is designed for sharing info. about ones' game being made (so there's no point to post there if you're making a game and don't want us to know anything about it). Just after you had completed the game you can announce it directly in the Completed game forum.

There used to be several people who never mentioned about game making in the production but announced they games when they're completed (some of tehm were amazing).

Don't use the test feature of the editor, it's not very reliable. Try saving the game, then go to the compiled folder of it and test it there instead.

I think it depends on how the screen interpolates the image, I think some of screens just produces ugly double (and triple, etc.) pixels (especially when the screen resolution is not a mulyiple of the displayed resolution, there'll be alternative single, double, etc. pixels which will be VERY ugly), some of the others added filters so the screen would be blurried out when it's not displaying in the set native resolution (IMO looks better then the former method, but still it cant be compared to CRT screens), and that's the reason I dislike LCD screens in general.
Actually I'm not very familiar with this kind of thing, the above are just experience I had after using several laptops, displaying 800x600 on a 1024x768 screen.

But if your screen is 1280x1024, I think it shouldn't be really bad displaying 320x240 or 640x480, for at least the horizontal res. 1024 is a multiple of 320 or 640.

Well, CJ is multiplying, all by himself, I guess...




Seriously, though, Phil, are you going to start some sort of ezine or just trying to be funny?

* Gilbot V7000a seconds GG.

And it's more flexible. Of course it can be annoying setting the properties one by one, but I think there aren't many practical use for obtaining the hotspot height in general currently.

Yeah there used to be a lot of stock of it here when it was released, I just ignored it as I never owned a Mega Drive.

Many AGS developers have been trying for months to give some possible 3D element to the engine, & it MIGHT have worked.

I just know that there're that many AGS developers...

The only way to find out is to try this for yourself. I already have & let me just say that you will be surprised at the bug fixes in this sucker!

I want to try but I'm not an AGS developer, and I'm surprised that you are.

2. [] Compile minimum checkbox. The editor for alll things not being used and cuts them out the compiled game. This could reduce file size.

Well it isn't that easy to implement I think, as teh AGS engine files are not currently destributed as separated modules, but single executable files, so it's not possible to remove some of the features of the engine under current condition (as when you "compile" a game in AGSEdit, what it actually does is just pack all the game resources with the engine executable). Furthermore, it'll require some real smart detection routine for the editor to decide what is redundent, and what is not, which would be quite difficult.
The same goes for sprites, views, etc., and it's even more difficult to check their usage (especially when they may be used in a script, they you may not be aware of). So I don't think this is a good idea.

It shouldn't be. Maybe it's some lame virus scanner that surfs the net for teh virus definition database whenever a new executable (ie. not executed before) is launched on that computer?

I don't think this can be made into a full contest thingie, since there're a lot of them already. If the person who is hosting (ie. defining the rules of) a Sprite Jam, Background Blitz, M$Paint game, he can always add such a rule in it in that particular contest.

Did you read the help?

Which game? I'd never heard of an AGS game accessing teh net (unless some plugins were used).

Hehe, and don't forget Bluecup on teh run.

Yeah I think that's quite interesting, but will even be better if it can be set separately for each room (ie if this is to be implemented, don't make it a general setting), as it's quite possible different rooms use different perspective.

[/*]

Actually my suggestion is that you may not do that unless you are REALLY conscious on what you are going to do. You can always comment that part of the code (simlpest way is to enclose it with /* and */) so you can save the codes for a bit longer, in case you still want it for reference, copying from it, etc.

Adjust the settings of your monitor, if any.

In that case, why don't you just buy the game and try it out first?