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 ... 435
The GUI type is "Normal, initially off". I have an object in a specific room which, when clicked on, displays the inventory.
As I mentioned before, the item displays fine after it is collected, but clicking on it doesn't change the cursor ><

Few more questions: does this inventory actually belong to the player, or to some dummy character?
Which cursor type do you click items with?
Can you put a breakpoint under "else if (button == eMouseLeftInv)" and see how it goes there?

Hm, two things to double-check:
1) In General Settings -> Inventory -> "Override built-in inventory handling" (should be True in your case);
2) In your code the mouse clicks are skipped if the game is paused. Does the inventory window pause your game (has "Pause game when shown" type)?
In that case I suggest first check inventory clicks, then do like:
Code: Adventure Game Studio
  1. if (IsGamePaused() == 1) // Game is paused, so do nothing (ie. don't allow mouse click)
  2.     return;
and then continue with the regular clicks.

(But you will probably have to adjust that further as you continue with development)

Yes, the error messages in script compiler are often broken. Also, the pointers become weird when used in conjunction with arrays.
In this particular case the problem is that you have declared a single pointer to Particle, which you then treat as a dynamic array.

You would need to declare dynamic array of pointers instead:
Code: Adventure Game Studio
  1. Particle* pRaindrops[];

On a side note, AGS supports "for" loop now:
Code: Adventure Game Studio
  1. for (int i = 0; i < 1000; i++)
  2.     pRaindrops[i] = new Particle;

There was a very similar question just recently. You are not posting your "on_mouse_click" code, but seeing iRatSkull_Interact code it seems that you went same way as the topic starter in that other thread, - by handling item selection in particular "interact" event, - which is very non-optimal. Perhaps the suggested solution will also work for you:

Updated the test build, now supports Software renderer too (this means 8-bit games):

Built on top of the latest 3.5.0 Alpha 7, so to test this you may install a copy of 3.5.0 somewhere and unpack the archive over it.

Still TODO:
- Better script API to manage the new viewport/camera functionality;
- Some optimisation for software rendering.
- more testing...
- Actually allowing room backgrounds of any size (less than game screen).

The "Approximate recipe" in a broader sense may be called something like "Improvise with the pattern" (forgive me for possibly awkward wording). Then, another example of this would be the second part of the Insult sword fighting, where you need to use the retorts that you've learnt in the first part against the previously unknown insults.
But then, the original examples of "approximate recipe" require to fit new items in known slots, while the example above require to fit known items into new slots. Does that count as same kind of puzzle or different one?

Also, how distinct these puzzle types are supposed to be? I think if we've tried to get to the barebones of the puzzle mechanic, some of the listed above are practically subset of others.
Guess the puzzles may be categorized by some internal mechanic, and - separately - by its representation.

Let's take same Insult swordfighting as an example again. Is not it the case of finding a matching key to the lock? Only the key and lock are defined not by the geometric shape, but by the phrase semantics.

Adventure Related Talk & Chat / Re: Left/Right clicking
« on: 17 Nov 2018, 19:25 »
Add a switch to let players choose for themselves?

When I click the pause button in VS while the game is stuck, it seems to be stuck in AGSGameWindow line 74 with call stack (not very helpful, I guess)

Not following all the story, but sometimes you may try switching to other threads in "Debug->Windows->Threads" and see if any of available thread stacks has any visible relation to the recent command you are stuck at.

I've just realized that this is about multiple items; how many are there going to be? You can use additional cursor modes and "any click" events, but I'm not sure about the UX.

Another option is to have all items on 1 cursor type and switch cursor graphic instead.

Script-wise, when cycling between cursor modes:
- when switching from a normal mode, you simply set next cursor mode;
- if next mode is inventory item mode, then you switch and set its graphic to the first item's sprite;
- when switching from inventory item mode you first check if there is next item, and if yes then change cursor graphic instead. If this is the last item, then switch to the next cursor mode.

But I agree with ManicMatt: this kind of UI sounds risky, people generally dislike having to cycle cursors because it may take more time to get to the wanted command, and it's easy to skip the one you need.

I like this a lot.

Arbitiarily low entity/pointer consttrains and other engine limits
(like lack of opengl/script performance and hassling with overlyobfuscating dynamic pointer workarounds)
made me do a tricky choice to abandon the AGS editor/engine for almost 2 years, and using other languages instead (mostly opengl).

To be fair, AGS did not improve that much since. Some constraints were easier to remove, but quite a few annoying restrictions still remain.

Time to make a
bridge to AGS, for all the CSG-rootsolging
spheretracking/raymarching of
if only for some cheap semi 2.5 d fractals/reflections or crepuscularity:

basic idea is to define assets with lots of space partitioning and smoothMinimum:

I don't think it is worth to expect something like this in AGS. I've said that before on many occasions, but AGS is a very old software focused strictly on 2D point'n'click games, and the way its coded makes it very difficult to add new stuff while keeping it consistent with existing game mechanics. Besides it is now being contributed to sporadically by just a few people.

It's easier to choose another engine that is already based around 3D. AGS will not necessarily suit your needs.

link to KB with "windows engine" is broken (404), pls fix

Uhh, this forum thread in 13 years old...

Not sure what were you searching for exactly, but some of the old engines may be downloaded using this torrent from AGSArchives:

In theory there is only one big feature left for me to complete, so I will hopefully find more spare time soon and begin fixing all the reported problems.

This is a common misunderstanding: when you assign BScreenshot1.NormalGraphic = buttonSprite.Graphic; this does not copy sprite to the button, but makes button remember dynamic sprite's ID. You must keep the sprites so long as your buttons have to display them, and only delete sprites later when the GUI is no longer shown.
Of course, since you have 5 buttons, you need 5 dynamic sprite pointers (as separate variables, or stored in array), otherwise all buttons will be showing last created sprite.

Actually, there was a postapocalyptic RPG made with AGS called "Dustbowl":

EDIT: oh, nevermind, I thought you were asking about making such game with AGS.

* GetWalkableAreaAt I just migrated my test project from 3.4.1 to 3.5.0 and it was working on 3.4.1. Coordinates are player.x and player.y. I think they are room coordinates?

According to the manual, GetWalkableAreaAt requires screen coordinates, so in scrolling room it will require adjustment with GetViewportX()/Y().
I will test that myself soon though, I recall we had some problem with detecting walkable areas (although that could have been another version).

* I can explain it with an easy example :
Code: Adventure Game Studio
  1. if (cChar.Frame == 35) {
  2. cChar.ChangeView(X);
  3. }

In this simple code, the engine doesn't wait to change the view till the frame number 35. Instead, It changes the view immediately. Whatever the the actual frame number is, the engine thinks It's 35 and executes the command.

But that's technically impossible if only Character.Frame is not working, it's about how "==" operator is working then, because Character.Frame itself cannot know what number you are comparing to. Either things are completely messed up in the engine, or there is something else in the script that affects that.
Could you for example log the current frame value somewhere, like print on a GUI label and see how it changes?
EDIT: I did a very simple test, which looks like this:
Code: Adventure Game Studio
  1. function repeatedly_execute_always() {
  2.   lblScore.Text = String.Format("Frame: %d", player.Frame);
  3.   if (player.Frame == 6)
  4.   {
  5.     lblScore.Text = lblScore.Text.Append("+");
  6.   }
  7. }
This prints character's frame value on label, and adds "+" only if it's particular frame.

* The Room pane gets broken over time and you can't access it,
Can you give any details?

and it's too slow, nearly uneditable.
Is this related to the zooming? (it's still may not be optimised for high-resolution games)

* GetWalkableAreaAt script command doesn't work anymore. The engine knows the player is on a walkable area but doesn't execute the command.
Only to make sure, are you passing screen coordinates or room coordinates in there?

* Character.Frame property also seems broken. Whatever the character frame is, the engine thinks it is always true.
Not sure what you mean here? Character.Frame is integer, so its always "true" (in boolean sense) if its above 0. How do you use it?

Beginners' Technical Questions / Re: Resolution
« on: 12 Nov 2018, 19:36 »
1) ... why isn't the highest possible resolution the best solution.

If player's system does not support the native resolution of your game, then they will have to play game downscaled, and with 2D engine like AGS upscaling works better than downscaling, latter usually makes the graphics much worse, especially the text.

2) When I am trying to work with the rooms with high resolution backgrounds, I can't zoom out enough, and it is complicated to work scrolling around the room all the time, or am I doing something wrong?

There is an old arbitrary limitation of zoom amount in the AGS Editor, which is hopefully going to be improved in the WIP 3.5.0 version.

My question was about "IgnoreWalkbehinds", because that's the only reason I know that may cause walk-behinds not work correctly when you are using any hardware renderer, and also make visible difference between software and hardware renderers. If you are not using that option, then it might be something else.

What renderer were you using with desktop and Android versions, and have you ever used "IgnoreWalkbehinds" option for characters or objects in your game?

Pages: [1] 2 3 ... 435