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 - Crimson Wizard

Pages: [1] 2 3 ... 367
So If I change the GUI to normal, initially off it works. No idea why it doesn't work when paused.

Does your on_key_press function has something like this:
Code: Adventure Game Studio
  1. if (IsGamePaused())
  2.    return;

It still doesn't work. When the GUI is open, the key doesn't seem to register.

Do you have any TextBoxes on the GUI? I think they catch all the key input.
Other than that, I cannot think of anything but maybe another script module overrides keypresses when it's open, if you have any.

Normally this should work:

Code: Adventure Game Studio
  1. function on_key_press(eKeyCode key)
  2. {
  3.     if (key == eKeyN)
  4.     {
  5.         gNotebook.Visible = !gNotebook.Visible; // switch GUI visibility to reverse of what it is now
  6.     }
  7. }

You can put this in GlobalScript.asc. If the script already contains function "on_key_press", then just add this new code into it.

Regarding your original code, you do not need to have separate NotebookOpen variable, because gNotebook.Visible already tells you if GUI is visible (remember, you can both set and get its value).

Ok then, next attempt:

This looks like a smiling ghost with a handle... or beard... or riding a wheel... or freud stuff again :).

I see you have a lot of sprites.
Is your sprite file at 2Gb? AGS can't handle more than 2Gb files. If so, you'll have to use a "work around"
Search the forum, there's a thread on how to solve this problem.

The symptoms are very likely indicate this problem. AGS still does not support sprite file over 2 GB. The two solutions available are:
1) Enable sprite compression in the general settings (unless you already did).
2) A not simple solution, but if nothing else works, you may keep additional sprites in separate file(s) and load them in script.

Need to also check 3.4.1, there were certain fixes to switch.

My game repo has currently 123MB and my game binary has 108MB, so I am not sure about the 1MB increase per object.

The game I was testing this out with is 1024x768 (that means large room backgrounds), and I was checking repository size after making commits. Every time I change something in a room, even if a property of a single object, it increased by the size of that room file (1-2 MB). That may not be a big deal if repository is on my HDD, but online services like bitbucket and github have limited storage for free accounts, so I was worried how large it may become, as game is still in the middle of developement and things are adjusted very often.

With sprites it was even worse, I added a single small sprite and repository became about 60 MB larger.

Maybe I was doing something wrong, or there are repository settings I am not aware about, but this all made me paranoid, so I excluded all binaries from repository and just left scripts there.

First of all, as the most straightforward solution, you could simply copy all necessary files to hosting like dropbox or google drive every time you end working on current machine (Or use a flash drive, if internet connection may be absent).
Of course this approach gives you little control over versions of your game, but then again, a lot of people seem to not use any (except for regular backups) and being fine with it.

If copying all files at once is a problem, and you want to copy only modified parts:
* modified scripts and Game.agf file (it contains dialogs, characters, etc descriptions of global entities in game) are text files that may be merged using tools like WinMerge or KDiff.
* new script modules may be copied and then imported into game project.
* new rooms may be copied and then imported.
NOTE: you only need to manually import rooms and script if you do not merge Game.agf. If you did, AGS will already expect these new modules to be present, so you just need to have them in folder.

Speaking of version control systems, they may greatly simplify sharing the project files once you learnt how to use it (may still take time). But there will be other issues with it. AGS is still not fully fit for version control because the rooms are saved as binary "blobs", and whenever you change a single thing in there version control thinks it's a completely new file. This causes their repositories increase in size rapidly, because they have to store history of all the changes (this is especially noticeable in hi-resolution projects with many rooms).

Real life example: I move one object in the room, and size of storage increases by 1-1.5 MB.

Same goes for game's sprites file, especially if it's compressed, version control seem to not being able to deduce that only part of it has changed, so every time you add 1 small sprite, repository may increase in many MBs.

For that reason, personally I exclude sprite file and rooms from version control (keep them as a separate archives with date in their name), but leave room scripts there, which are still texts.

The documentation on Wiki pages you linked above is extremely outdated, and seems to not been maintained for years. I suggest to always use help file that comes with the Editor.

AGS Games in Production / Re: Unavowed
« on: 20 Sep 2017, 12:58 »
Devstream #4!

Randomly clicking onto middle of the video, watching how character is tying a red ribbon between two objects. Remembering a puzzle from intro scene where you have to do similar thing to a wire.
Is this a game about connecting things together? :D

But I create an executable. run winsetup; say run in window mode, save it. then I zip the game with the config file and download it on another computer. and it does not run in window mode unless I run setup again in the other machine. so, whatever I set config to, does not seem to work when I run in on anther computer.

Ah yes, I was wondering if that's this problem.
When you use winsetup it saves config not to file in game folder, but to the file in user folder (%USERPROFILE%/Saved Games/<Name of your game>/, which is "C:/Users/<user>/Saved Games/" on Windows 7 and later). This creates an issue when you may think you changed default config for your game, but instead change personal config that is stored in personal settings.

For that reason I added new "Default Setup" window to the Editor in AGS 3.4.1 (will be released soon).

As for 3.4.0, there are two workarounds:
1) When you are about to distribute your game, copy acsetup.cfg from your personal folder, not from game folder.
2) Edit acsetup.cfg in the game folder by hand. That's a simple INI file, instructions are here:

1) full screen mode should automatically scale the game to take up the entire screen. and the game should default to window mode if possible( without the need to run setup).
This is done by setting "stretch to full screen" in setup. It is defaulted to "max round scaling" for historical reasons. As eri0o noted, if you send acsetup.cfg with your game, players will use your settings as initial ones before setting their own.
EDIT: actually I could default this to "proportional stretch". Round scaling may be essential when running low-resolution games on irregular display resolutions - that may cause uneven scaling with some pixels scaled twice and others not scaled, which is noticeable if game is 320x200 for example.

Removing background frames limit nad playing video on background or arbitrary object may be a good thing, but meanwhile - alternatives are animated room-sized object positioned below everything else, or scripting drawing sprite on room background with timeout (may be slower though).

EDIT: To be frank, it is safer to assume that there won't be much big change to this engine. Development has stalled in last years, and there was never much people interested in it anyway. Engine is based on obsolete technology that runs worse and worse on every new operating system. I believe that the future is with alternative engines or complete rewrite (I know some people around here are trying to do that).

Ah, that might be what it is. I've just been sending out the EXE, not the associated Winsetup or audio.vox. Again, stupid newb question - will the person receiving these files need to do anything special to implement them? Or will it be okay if the file is just in the same folder? Sorry to seem so inexperienced, but this is the first time I've done something anything like this.
Yes, you need to send them all, because they are all part of the game. Audio.vox contains digital audio and winsetup is a setup program. Without winsetup.exe player won't be able to configure the game (well, there is a way, but it requires additional manipulations that are not obvious).
No additional actions needed usually, players just unpack the archive. Then they may run winsetup to change configuration or just run the game.

Yeah, that's where I'm getting it from, as far as I know. I go in there, grab the .EXE file, and save it to my various upload folders and whatnot. The guys who've volunteered to playtest the game says the game works fine - except for the music. And yeah, it's only the music that doesn't play - the sound effects work just fine. As for Winsetup, I don't think I've even touched that, beyond changing the screen resolution.
Ok, so it is not you who does not have the music, but another person? You say you "grab the .EXE file", what do you have in your uploaded package exactly, is it just exe, or other files too (vox, cfg)? Normally you would copy everything from Compiled/Windows folder (except debug logs "warning.log").

Do I need to update the engine? Will that effect my game if I built it in 4.3.0?
No. Also, there is no 4.3.0...

Looks like I'm using the 3.4.0 version. How does that affect how audio/music is complied?

Hm, maybe it does not... we had several music-related bugs during development of 3.4.1, that is why I asked.

Where do you take final games files from? In 3.4.0 that should be Compiled/Windows.
Are you sure that you did not disable music in winsetup? Is it only music that does not play (do other sounds play, if you have any)?

What is the exact version of AGS you are using?
Note: music.vox is a deprecated name from AGS 3.1 and earlier. Now it is called audio.vox.

Editor Development / Re: minor bug in the editor : undef
« on: 19 Sep 2017, 21:20 »
Interesting, there was already a bug fix for crash when typing "#define". Maybe this is another half of same bug?

So newest ags has that?
No. I mean, this probably would be best solution to add one.

By the way, don't other d3d9 games not working on Windows 10, or its just AGS?

Probably not the best idea, but it will be a long time before my game is done, so I assume 4.1 will be made final (or close to it) before that.

Actually that's a good idea because it makes more extensive testing and serious issues may be dealt with earlier :).

As for the final 3.4.1, I really was going to finish it with OpenGL's vsync, but now since eri0o reminded of that old bug with portrait positions, I might as well try to make a fix to it too.

Thank you for pointing these places out, but I will have to do research first anyway. When I said "ugly code", I meant not only that it is not very clean, often there are strange connections between variables and parameters, you change something in one place and it suddenly breaks something seemingly unrelated...

Pages: [1] 2 3 ... 367