Quote from: MecaCool on February 11, 2020, 12:00:19 PM@Drahsid Some advice if you do some coding in not just the "dll" project but also the modifying of the application project then you need to release the new build.You, can't expect someone to use an outdated Mupen64Plus with your "dll" because it shares as a reference and called from the application project no matter if you just did code from one project alone.This is absolute nonsense, you don't understand how Mupen64Plus is structured. Go ahead, compile my fork. You'll realize that the output is just the dll. Most front ends are garbage, but should still work if their executable is from the latest version of Mupen64Plus. All you need to run this is the dll and the script, exactly what I provided. There is no mistake in what I released. The only issues that is related to Mupen is with the input plugin, which seems to be an SDL problem. Nothing to do with having a more up to date library. Quote from: MecaCool on February 11, 2020, 12:00:19 PM@Drahsid compile your fork and update your post with new links to the new fork build project so people will not have issues with your mouse input goodie He should have known that prior before he released this @Drahsid. But a simple mistake I'm sure.You should try it. It might clear up your confusion.
@Drahsid Some advice if you do some coding in not just the "dll" project but also the modifying of the application project then you need to release the new build.You, can't expect someone to use an outdated Mupen64Plus with your "dll" because it shares as a reference and called from the application project no matter if you just did code from one project alone.
@Drahsid compile your fork and update your post with new links to the new fork build project so people will not have issues with your mouse input goodie He should have known that prior before he released this @Drahsid. But a simple mistake I'm sure.
Editing the "mupen64plus.cfg" here is necessary.I also used this site as a reference:http://en.qi-hardware.com/wiki/Key_codesSo far i got "Escape" To Menu, the usual WASD to the C Buttons, Q and E are B and E, Space is "Jump".Now here is what i don´t get.Other keys such as "Left Ctrl" for "Control Pad Down" isn´t working.I´m not really sure what is causing this. Left Ctrl should be "305". Yet it still wouldn´t work for that key. It just baffles me that i "somehow" got the other Keys working so far. I have no clue what is preventing this now. Other sites claim it should be "17" and not "305". Still wouldn´t work either.Edit:I got it to Shift (304) instead of Ctrl, which isn´t the way i want but at least it´s working.Still doesn´t explain why Ctrl isn´t working. Now does anybody have an idea how the Mouse Buttons are called?It seems to be the only thing left and i could share my config for the controls.
Latest Mupen64Plus + Mupen64PlusQT launcher + GlideN64 + Input Plugin from this thread's OP(in the bug list).DPad R = "mouse(2)"DPad L = ""DPad D = "key(306)"DPad U = ""Start = "key("Z Trig = "mouse(1)"B Button = "key(50)"A Button = "key(49)"C Button R = "key(100)"C Button L = "key(97)"C Button D = "key(115)"C Button U = "key(119)"R Trig = "key(32)"L Trig = "key(120)"Mempak switch = "key(44)"Rumblepak switch = "key(46)"
Controls:Left Mouse: FireRight Mouse: Sniper Zoom1: Change Weapon\A Button2: Change Weapon\Activate Gadget\B buttonSpacebar: JumpCtrl: CrouchWASD: MoveBackspace: Pause
Secondly, i'm having issues. The camera is always jiggling. Its almost as if the camera is fighting back against the mouse or perhaps its not super smooth.
Furthermore, unrelated to this mouse script, my sound is always out of sync.
Another thing. Is there anywhere to unbind the number keys from choosing save states. I like to use 1 and 2 as my change weapon buttons.
Here's some gameplay: https://youtu.be/a__BK2yWF5kI believe this project deserves so much more attention. Its unlikely that we will get a port for T3 and I can imagine that this project must of took alot of time and effort.
I can't reproduce this myself. It is possibly related to the QT launcher, or perhaps you have the joystick set to the mouse in Mupens config (DONT DO THIS, the mouse input is not linked to the joystick)
That's a Mupen issue, I think changing the sound-sync type might have better potential results.
afaik these are near the top of Mupen64plus.cfg
Thanks for the support. I dunno if I'll update this in particular, but I am doing a lot of reverse engineering on Turok 3 itself. In the future, I'm sure an official Turok 3 port is possible.
I looked the the entire cfg and couldn't find it . It doesn't seem like you can customize that anywhere. For now I will map the buttons to Q and E. https://mupen64plus.org/wiki/index.php?title=Mupen64Plus_Core_Parameters
Are your intentions to create a port? As a undergrad CS major, being able to create a port using the resources you have is mindblowing. Your work deserves more support, especially on these forums. Infact, I think your script would bring more attention to the game and therefore would increase the speed of us getting a official port.
IIRC, Kaiser (Turok Remastered) had access to very little official code when he was first making his port. T3 unofficial port should be fairly possible right?
EDIT: Is there anyway to reduce the input lag? Furthermore, i've still had no luck with solving the audio delay. What is your audio setup?
A "Rage Wars"
Hey, can you post which version of GlideN64 are you using?, I'm using one dated May 6 2020, using your same setup crashes on start up, Glide64 and Rice crashes after choosing a character...I originally tried to use it with an m64p dated April 9 2020 and it just doesn't work, it's probably something to do with m64p though...I've read that thread in the Turok forums like 20 times...I've also added the corresponding [Input-SDL-Control1] to the .cfg (I didn't even know you could do that)...I've also used the scan codes posted in that thread, I just don't know what I'm doing wrong...
[Input-SDL-Control1]# Mupen64Plus SDL Input Plugin config parameter version number. Please don't change this version number.version = 2# Controller configuration mode: 0=Fully Manual, 1=Auto with named SDL Device, 2=Fully automaticmode = 0# Specifies which joystick is bound to this controller: -1=No joystick, 0 or more= SDL Joystick numberdevice = -2# SDL joystick name (or Keyboard)name = "Keyboard"# Specifies whether this controller is 'plugged in' to the simulated N64plugged = True# Specifies which type of expansion pak is in the controller: 1=None, 2=Mem pak, 5=Rumble pakplugin = 2# If True, then mouse buttons may be used with this controllermouse = True# Scaling factor for mouse movements. For X, Y axes.MouseSensitivity = "2.00,2.00"# The minimum absolute value of the SDL analog joystick axis to move the N64 controller axis value from 0. For X, Y axes.AnalogDeadzone = "4096,4096"# An absolute value of the SDL joystick axis >= AnalogPeak will saturate the N64 controller axis value (at 80). For X, Y axes. For each axis, this must be greater than the corresponding AnalogDeadzone valueAnalogPeak = "32768,32768"# Digital button configuration mappingsDPad R = "mouse(2)"DPad L = ""DPad D = "key(305)"DPad U = ""Start = "key(13)"Z Trig = "mouse(1)"B Button = "key(101)"A Button = "key(113)"C Button R = "key(100)"C Button L = "key(97)"C Button D = "key(115)"C Button U = "key(119)"R Trig = "key(32)"L Trig = "key(108)"Mempak switch = ""Rumblepak switch = ""