If you programmatically put a DragElement directly into a container, like putting an item into an inventory slot, even if setUseLockToDropElementCenter(true); is used, the DragElement will not be centered.
The container is 50x50, the icon 48x48. I want an outline, but you can imagine it doesn’t look very good. As soon as the DragElement is dragged or even clicked on, it centers itself.
Anyway, that’s just a FYI post. 
You can fake a mouse event to place the element.
In that case it should be a breeze for you to fix it by faking a click.
@madjack said: In that case it should be a breeze for you to fix it by faking a click.
?? How could I know if/when you are doing this? /boggle
Where exactly would I add this?
You’re funny, did I ever tell you that?
The post is a FYI, not a request for a support. The feature is supposed to have it centered in its parented element, it’s not working when directly attached. This is called a bug where I come from. shrug
That you fix it or not, I don’t care, I’m trying to be courteous in telling you it’s not behaving as promised.
That’s all.
No need to reply or argument on the fine point of “bug” definition.
@madjack said: You're funny, did I ever tell you that?The post is a FYI, not a request for a support. The feature is supposed to have it centered in its parented element, it’s not working when directly attached. This is called a bug where I come from. shrug
That you fix it or not, I don’t care, I’m trying to be courteous in telling you it’s not behaving as promised.
That’s all.
No need to reply or argument on the fine point of “bug” definition.
/sigh. You report a problem and I gave you a solution for the problem.
In response to my suggestion you tell me I should have no issues fixing it then.
I’ll be glad to fix it… if you can help me figure out how I could possibly guess what your intent is. I have nothing to work off of without this info.
This is the second issue you have reported in the last week that is specific to your program that you are insisting is a library issue that needs to be resolved. The first of which I was willing to provide an alternate solution to. I’m willing to look into possibilities here as well, but don’t ya think you could take a sec to help me understand wtf you are asking for here so I CAN provide a solution for it?
Yes, because Ochlocracy is the ONLY program that uses an inventory. Yep.
So, in the real world of games with inventories, you expect what? That when a server tells a client it has received an item, the “DragElement” will be stuck to the mouse cursor and not dropped into one of the gui slot? That the received items are handled by the player, that he should drag them to the slot he wants it in?
No, it gets sent to the gui which places it where it belongs.
If you want a suggestion, provide a method inside DragElement to attach to a parent. dragElement.stickMeHere(someDroppable); Then check if the centered flag has been set. Or whatever.
My point here is you offer a feature but it only works within certain parameters. This is referred to as a bug. I only wanted you to be informed of it.
Next time I’ll keep my suggestions and reports to myself.
@madjack said: Yes, because Ochlocracy is the ONLY program that uses an inventory. Yep.So, in the real world of games with inventories, you expect what? That when a server tells a client it has received an item, the “DragElement” will be stuck to the mouse cursor and not dropped into one of the gui slot? That the received items are handled by the player, that he should drag them to the slot he wants it in?
No, it gets sent to the gui which places it where it belongs.
If you want a suggestion, provide a method inside DragElement to attach to a parent. dragElement.stickMeHere(someDroppable); Then check if the centered flag has been set. Or whatever.
My point here is you offer a feature but it only works within certain parameters. This is referred to as a bug. I only wanted you to be informed of it.
Next time I’ll keep my suggestions and reports to myself.
Inventory != GUI Library
Server & Network Messages != GUI Library
You’re asking for a game specific feature for the library. I’m not even sure what you mean by “Stuck to the mouse cursor” or “Server tells client he has received an item”??
The simple solution is to provide a mouse event so the drag & drop elements are aware of each other. There is no way I could know what your intent is or that the drop element is specific to the drag element in this case (or any for that matter), especially when words like Inventory and Game are involved. If I was to blindly attach a drag element to drop element based on proximity, within a week this would be reported as a bug as well.
Help me understand this and I can at a minimum fiure out if it is possible to provide a working solution
I. Effing. Give. Up.
@madjack said: I. Effing. Give. Up.
I take it you have no intent on throwing me a bone here so I can figure out a solution?
I already gave you a solution:
If you want a suggestion, provide a method inside DragElement to attach to a parent. dragElement.stickMeHere(someDroppable); Then, when it's called, check if the centered flag, and all other relevant flags has been set and act accordingly. Or whatever.
@madjack said: I already gave you a solution:
Hey! Sorry I missed this.
Let me see what I can do with this and if it is possible. I’ll let you know if/when it is available.
@madjack said: I already gave you a solution:
Ok, I’ve commited an update for DragElement that contains the method:
[java]
DragElement.bindToDroppable(Element el);
[/java]
I tested this with the inventory test I put together and all seems to work fine. Let me know if this works for you so I can update it if needed.
Made a small change to parent droppable in DragElement. Just a heads up that this changed slightly, so you’ll want to grab the latest commit.
Didn’t work at all here. The element ended up in the corner of the screen, caused crashes when clicked on, etc.
Here’s a working fix. This is pretty much exactly my suggestion verbatim. I provide a droppable and the method checks if centering is enabled. I don’t do anything else, so if you wanted you could check all the other possible states, if any. I’ll keep that in my repo.
[java]public void bindToDroppable(Element dropEl) {
if (dropEl.getIsDragDropDropElement()) {
if (lockToDropElementCenter) {
Vector2f destination = new Vector2f(
(dropEl.getWidth()/2)-(getWidth()/2),
(dropEl.getHeight()/2)-(getHeight()/2)
);
if (useLockToDropElementEffect) {
slideTo = new Effect(Effect.EffectType.SlideTo, Effect.EffectEvent.Release, .15f);
slideTo.setElement(this);
slideTo.setEffectDestination(destination);
screen.getEffectManager().applyEffect(slideTo);
} else {
setPosition(destination);
}
originalPosition = destination.clone();
}
dropEl.addChild(this);
}
}[/java]@madjack said: Didn't work at all here. The element ended up in the corner of the screen, caused crashes when clicked on, etc.Here’s a working fix. This is pretty much exactly my suggestion verbatim. I provide a droppable and the method checks if centering is enabled. I don’t do anything else, so if you wanted you could check all the other possible states, if any. I’ll keep that in my repo.
Um… can’t repro any of what you have stated here. The current method let’s the DragElement do what it should have if you had dropped it over the drop element… i.e. It does NOTHING other than set the forced event element to the DragElement and pass the screen method a bogus mouse release. If you’re seeing issues with this, then you’ve done something wrong. Here is the method:
[java]
public void bindToDroppable(Element el) {
if (el.getIsDragDropDropElement()) {
float x = el.getAbsoluteX()+(el.getWidth()/2);
float y = el.getAbsoluteY()+(el.getHeight()/2);
MouseButtonEvent evt = new MouseButtonEvent(0, false, (int)x, (int)y);
if (screen instanceof Screen) {
((Screen)screen).forceEventElement(this);
((Screen)screen).onMouseButtonEvent(evt);
}
}
}
[/java]
Seriously… this is the EXACT same as releasing the drag element over the drop element.
What do you have the DragElement attached to prior to calling this method?
Instead show me how you did it if it works. That’ll be MUCH easier than trying to diagnose what I did.
@madjack said: Instead show me how you did it if it works. That'll be MUCH easier than trying to diagnose what I did.
How about answering my question so I can?
I have a feeling you have the element attached to nothing. The UI has no reference to the drag element existing. If this is the case, I’ll add a check to make sure the parent of the DragElement isn’t null. However, you can just add the new element to the screen before calling the method, as the UI has to know it exists.
EDIT: Actually, I’m going to add this check anyways… I think it should probably take it a step further though. It needs to remove it from it’s current parent (if it is not at the screen level) and add it to the screen. The way the drag element works does just this when you pick it up. In the test I put together, I was adding it to the screen because originally, I wanted to make sure the drag event would start even though the drag element didn’t exist when the scene was clicked…
@madjack
I updated the method to hopefully account for all possible states the DragElement could be in:
if attached to an element - removes
if not attached to the screen - adds to the screen.
This should fix any issue you may have seen.
In the process of changing this, I think I tracked down the other issue you reported with the ConflictingIDException not being thrown in all circumstances. Grab the latest commit for Element as well.