Jump to content

Kayl

Members
  • Content Count

    70
  • Joined

  • Last visited

Community Reputation

0 Neutral

About Kayl

  • Rank
    Transformer

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. I think it's pretty well coded, as it would let you have both a modded object and don't mess the GTA world with the same object ID You can't really say that you are left with the freedom to have both a modded object and an untouched GTA world object because the moment your MTA object is streamed in, the GTA world object changes as well. When you replace an "ID", you expect all instances to be replaced. If it was that well coded, it would either replace also GTA world objects without the need for a hack, or provide us with an option to say if we want only MTA objects affected. Right now we h
  2. That's indeed the technique used for this DKR sign. A ghost (alpha = 0) MTA object is created at the same location as the GTA object to guarantee the streaming in of the MTA object will force the GTA object to be "updated" accordingly. I wish this was not necessary.
  3. <script src="..." type="client" />
  4. Thank you very much for sending me your file. Thanks to it, I was able to spot the problem. It was a QtToLua bug introduced when the export of scroll bar was created. Scrollbar of scrollareas where also exported as standalone scrollbars when they shouldn't be. I have therefore released version 0.1.7 of QtToLua http://dkrclan.com/qttolua_data/download/QtToLua.zip which fixes the aforementioned bug. I have tested it with your file and it works fine now. You are free to use layouts or not, the problem was not coming from that. Thank you for your feedback which helped me fix this issue.
  5. From what I see you don't use layouts which might explain a mismatch when going from Qt to MTA, also when you create a new window, choose widget or dialog, mainwindow is useless since menus are not part of MTA. Apart from the layout suggestion, I don't see what the problem could be, could you send me your UI file so I can have a look?
  6. Vice > The example resource shows how to show/hide the window with a command. In your code for your own window, simply use http://wiki.multitheftauto.com/wiki/BindKey to bind F5 to your command/function showing the GUI. dukenukem > No. Qt with C++, hence "Qt to Lua".
  7. As far as I know, the very definition of dimension is that all elements in other dimensions than the current local player's dimension aren't streamed in² for the local player, they are merely element information that will only be transposed to GTA world "objects" if the player is in the right dimension and the surrounding of it. The GTA clientside version of the car is "gone" not "hidden" for the client so there is no way his GTA physic engine could continue syncing it correctly so I fairly doubt MTA would let him be the syncer of it. So for me, forget about the car issue since I think it's a
  8. That's because of euler rotation order. Cf: viewtopic.php?p=326214#p326214 Objects in MTA are ZXY whereas vehicles are ZYX, meaning (for objects) rotation about world Z, then rotation about resulting X and then rotation about resulting Y (for objects). So the result is different depending on the order. Most people use moveObject to rotate about one axis at a time and on objects that have 0 rotation on X or Y so the problem is not seen for those. The editor uses a patch, similar to the lua code you will find in the topic post above, to make objects rotate with ZYX and not ZXY. It has now be
  9. Kayl

    Compiling LUA

    Even if you do use an external webserver it shall be configured so as to give access to the resource-cache folder (not the resource one) which only consists of the latest versions of all required clientside files. Only if the webserver was poorly configured would it give access to mta serverside files.
  10. XX3 > Indeed the end goal is to be able to attach object like hats or other items to a ped. Both problems need to be resolved to be able to do that correctly (for the orientation one, the hack I currently do in the head only works for some skins, providing the orientation of any bone would allow me to make it work for all). benxamix2 > I don't want to attach the object to the root bone of the ped but to a specific bone which, during animations, changes offset and orientation. But as I mentioned, this topic is more about the positioning than the rotation (which can be hacked for most sk
  11. Hi there, I'm trying to play a bit with bones. I'm trying to "attach" an object relatively to a bone. The first problem concerns the position of the bone (here, a bone in the head). It appears that, in order to have the object following the bone smoothly, the getBonePosition + setElementPosition (on the object) must be done onClientPreRender. However, when walking on steep slopes, it seems GTA changes the bone position between onClientPreRender and onClientRender, I guess it's a result of inverse kinematics being performed to make the ped's feet touch the ground and adapt the current anim
  12. Kayl

    Element Rotation

    Ok, I have posted the new patch that contains also serverside changes: http://dkrclan.com/qttolua_data/eulerPatchFull.patch It was a bit simpler since serverside peds only use Z and don't have this -Z(set) +Z(get) problem. Here is the serverside test code that goes with it. addCommandHandler("stest", function () local spacing = 20 local x, y, z = -1375.1043701172, -25.0885887146, (14.1484375 + 5) local modes = { "default", "ZXY", "ZYX" } local elementsConf = { [70] = {createPed, 2}, [519] = {crea
  13. Kayl

    Element Rotation

    Thx to our PM discussion, I was able to compile MTA. Here is a first version of the patch: http://dkrclan.com/qttolua_data/eulerPatch.patch I would have liked to upload it on the bug report but I'm getting access denied. The test code for it: addCommandHandler("test", function () local spacing = 20 local x, y, z = -1375.1043701172, -25.0885887146, (14.1484375 + 5) local modes = { "default", "ZXY", "ZYX" } local elementsConf = { [70] = {createPed, 2}, [519] = {createVehicle, 0}, [1681] =
  14. Kayl

    Element Rotation

    In order not to brake compatibility, an extra parameter to get and set could be used to specify the rotation order. By default, this order would be what it is now depending on the element type. setElementRotation(object, rx, ry, rz) would be same as setElementRotation(object, rx, ry, rz, "ZXY") getElementRotation(object) would be same as getElementRotation(object, "ZXY") same goes for vehicle and ped/player with their respective current rotation order. Like that, old scripts keep working, but at least those desiring to use unified versions could do so by passing the same order to all thei
  15. Kayl

    Element Rotation

    I know I'm answering to myself, however if I were to continue on the same post it would start to be way too long. So, since yesterday I have figured out what was wrong, or actually, why the code provided worked when it shouldn't have. The "patch" I based my fix on labeled the rotations wrongly. After intensive testing and headache, I can make the following statement with confidence: 'When calling setElementRotation(rx, ry, rz), MTA applies the rotations in the following order : - for objects: ZXY - for vehicles: ZYX - for peds: -Z-Y-X When doing getElementRotation, peds are bugged and r
×
×
  • Create New...