I'm looking for even a single example of an item "Equip:" effect which is intended to expire after a set duration, rather than being an indefinite aura which remains until the item is unequipped. Specifically the "Equip:" effect itself, disregarding any proc or other secondary effects which result from the initial effect defined on the item.
I hope this is the right place to ask, as this is a broad knowledge question that informs a potential code change in a very generic core function. Any counter-examples would help to refine the code change or invalidate the planned approach.
Related
I'm a bit new to GMS2 and am having a bit of a problem.
In the current state of my game, you start in a useless room that only exists to initialize global variables and a persistent object. This room then switches to an actual level. All of this occurs in the creation code of the first room:
globalVars();
instance_create_depth(-2*global.tile_size, -2*global.tile_size, 0, OBJ_UTIL_manager);
room_goto(2);
Upon switching rooms, only some of the instances appear. In particular, only objects without a parent or with one certain parent appear. Objects with another type of parent do not appear. They are present in the room builder. They DO exist, but are invisible.
The same room, if moved to the top of the room queue and therefore being the first room created, works just fine as long as I add the above global variable initialization and manager object creation. Is there anything special that must be done when switching rooms to make things visible?
This is how the room appears in the editor: http://prntscr.com/lg2x3w
Compared to how it appears upon being switched to: http://prntscr.com/lg2wdg
I do not know the full detail of the problem, but I did have a similar issue, so I can tell you a solution without actually knowing what went wrong, but anyways hope it helps.
Firstly, use the instance_create_layer instead of instance_create_depth and make sure that these layers where you create your objects exist in both the first "fake" room and the actual room.
secondly, make sure you do not have any code that change the depth/layer in the create event. [again I do not know why this could cause an issue, but it did cause an issue to me, so maybe you have the same issue/solution]
tl;dr
In a program that calls a function onEnterFrame on each frame, how do you store and mutate state? For instance if you are making a level editor or a painting program where keeping track of state and making small incremental changes are tempting / enticing / inviting. What is the most performany way to handle such a thing with minimal global state mutations?
long version:
In a interactive program that accepts input from the user, like mouse clicks and key strokes, we may need to keep track of the state of the data model. For instance:
Are some elements selected?
Is the mouse cursor hovering over an element, which one?
How long is the mouse button held down? Is this a click or a drag?
We also, sometimes need make small changes to a large model:
In a level editor, we may need to add one wall to an existing large set of prefabs. You don't want to recreate the set, no?
Read Prof Frisby's mostly-adequate-guide so far, there are many functional solutions to issues that deal with extracting a piece of data from some source of input, performing computation on that data and passing the result to some output.
Sometimes an app let's the user interact and perform a sequence of mutations on data. For instance, what if a program let's the user draw (like Paint) on a canvas and we need to store the state of the painting as well as the actions that led to that state (for undo and logging/debugging purposes)?
What state is acceptable to store and what should we absolutely avoid?
Currently my conclusions is that we should never store state that we only need temporarily, we should pass it to the function that needs it directly.
But what if there are several functions that need a specific computation? Like the case in which we check if the mouse's cursor is hovering over a specific area, why would we want to recompute that?
Are there ways to further minimize mutations of global state?
Storing state isn't the problem. It is mutating global state that is the problem. There are solutions to handling this. One that comes to mind is the State Monad. However, I am not sure this is ideal for undoing operations. But it is a place to start.
If you just want to look at the problem as an initial state and a set of operations then you can think of the operations as a List that can be traversed (with the head being the latest operation). Undoing a set of n operations could be accomplished by traversing the first n elements of the list and cons-ing the inverse of these operations to the list.
That way you don't modify global state at all.
I have the following problem:
I have a list of Components, that contain Rectangles with a width of either 200 or 800. I'd like to filter this list, and only create objects of the Rectangles with a width of 200 as I work on a small screen.
Preferably I do not want to create all objects, check their width, and destroy those with the wrong width again. For obvious reasons I really only want to create those with a width of 200.
To do this I would need to aquire knowledge of the width, before I instantiate them.
As far as I have seen, there is no publicly available and documented way of introspecting/reflecting the Component prior to it's instantiation.
My question is: Is there a non-public way to gain knowledge about what is packaged inside of my Component? Might it be possible with C++?
Or would it at least be possible to find out what kind of Object is encapsulated? Whether it will be a CustomComponent1, a Button, a RedRectangle...
Unfortunately not. You can't even predict it, since the Component could even point to a qml file that hasn't even been downloaded yet, if it was fetched from the network.
There are a couple of things you can try though, if you have room to approach the problem from another angle:
What you can do is pass properties from outside the component into it as it gets created. Assuming you control the code within the Component, you can then adjust how the internal elements get created based on the value of the property(ies) that was(were) set from outside.
If that's not good enough, say your Component provides multiple elements and you only want to create the ones that match your criteria (possibly a combination of many), then you can introduce a second Component layer within the first Component, and have that second Component either create the actual element if it matches your criteria, or an empty Item{} if it doesn't, which is as close as it gets to not creating anything.
I hope that helps!
I'm working on a graphical shape editor that uses the QGraphicsScene/QGraphicsView as its basis. I have a lot of experience with the scene/view framework and understand it fairly well. The issue that I'm having is that QGraphicsScene::items always returns items in the insertion order (either ascending or descending) regardless of the Z-order or the use of QGraphicsItem::stackBefore call.
The issue is that, as with most graphics editors, I need to be able to move shapes forward or backward in the stacking order. At the end, to save the resulting data, I have to traverse the list of the items in the scene and save each item's data in whatever format I'm using.
The only way that I've found to do this is that I have to remove items from the scene and reinsert them in the desired stacking order. In this particular task, it's a small number of items and happens without noticeable delay, but in a related editor, it could be many thousands.
While the QGraphicsItem::zValue and QGraphicsItem::stackBefore allow me to influence the drawing order, neither of them changes the order that gets returned from QGraphicsScene::items. Since the data I ultimately save needs to reflect the drawing order, I have to remove and reinsert to get the correct ordering at the end.
Questions:
Have I've overlooked any other techniques for managing items within the scene that will influence the results of QGraphicsItem::items?
Or is there another method for traversing the items within the scene that will give me the drawing order?
I can confirm that QGraphicsScene::items() and items(sortOrder) return the item list in the original creation and stacking order, which does not at all agree with the docs.
However, I found that by using
QGraphicsScene::items( QGraphicsScene::itemsBoundingRect, Qt::IntersectsItemBoundingRect, sortOrder) I do get the items in the correct drawing order, so this function apparently takes calls to QGraphicsItem::stackBefore() into account.
i don't use the z-order feature so I can't comment on whether that works in this scenario or not.
Ok I have an object and a big square as well as other stuff in a room. I need the object which is obj_dot to randomly spawn but only within the big square (which is obj_paper) every time the room restarts.
Your question lacks detailed information on the setup of your sprites/objects, therefore this answer might not suit you 100% but hopefully it will provide you with a general idea of how to go about resolving this issue.
You probably want to put something like this within the create event for an object that is created on the room creation. I'm going to assume obj_paper is created on room creation (hence is recreated on room restart).
In the create event for obj_paper, type the following using GML.
//Assuming the sprite for obj_paper has it's x & y positioned in the center of the sprite
instance_create(irandom_range(x-sprite_width/2,x+sprite_width/2),irandom_range(y-sprite_height/2,y+sprite_width/2),obj_dot);
That should do the trick nicely.