The way a data_array was iterated in the original release was incorrect. In the next release, data iteration has been corrected (and it now uses the actual data iterator mechanism)
Printable View
The way a data_array was iterated in the original release was incorrect. In the next release, data iteration has been corrected (and it now uses the actual data iterator mechanism)
I have got some things working now, including moving objects in game with OS but of course there are bugs. :saddowns: In the end of the video, I demonstrate moving of objects, click-n-drag style. The problem is some objects don't render when moved in certain positions and based on where you are standing. I think it has to do with the portal it is in, but if anyone knows as to why let me know.
The main problem I am having is with mouse button states. In the following first minute of the video I am holding down left mouse button the entire time, sometimes the gun fires and sometimes it doesn't. It only does when you change your x or y angle about 45 degrees or more. If you are looking straight forward, it doesn't fire which is what I want since I am hijacking the mouse.
I guess a way to solve this would be to just remap the mouse button control settings to unused. This code is inside the Input hooked update function. I check for mouse button state and set it to zero. My question is why are weapons still firing at certain angles even though I set the mouse button states to null?
Code:void Update()
{
Objects::object_data *object;
if(Forge::IsForgeOn)
{
if(IsInGame() && !IsInMenu() && !IsInChat())
{
object = Forge::GetClosestObject();
if(!object)
return;
if(GetKeyState(Enums::_KeyLShift))
Forge::selected = object;
if(GetMouseButtonState(Enums::_MouseButton1))
{
Forge::MoveObjXY(Forge::selected);
SetMouseButtonState(Enums::_MouseButton1, 0);
}
if(GetMouseButtonState(Enums::_MouseButton3))
{
Forge::MoveObjFront(Forge::selected);
SetMouseButtonState(Enums::_MouseButton3, 0);
}
else if(!GetMouseButtonState(Enums::_MouseButton3))
{
//Forge::holding = false;
}
if(GetKeyState(Enums::_Key0))
Forge::HoldDistance += 0.03f;
if(GetKeyState(Enums::_KeyDown))
Forge::HoldDistance -= 0.03f;
}
}
}
GetKeyState() with certain keys seems to not be working. It could be my code, but everything seems right. I also noticed the key indexes are custom, they aren't the same as Windows virtual key codes. :saddowns: sad face
Just something cool I figured out since Halo doesn't use SetTransform(), through vertex shaders I can project 3d vectors from object space into 2d screen space for even custom objects. The WorldToScreen I wrote is very buggy. I can't wait to implement this in OS!
This works 100%. What keys are you trying to use?Code:if (GetAsyncKeyState(0x47) & 1)
Yes, that does work, but it's really not reliable. I rather check key states that Halo has updated for me instead of calling an API. Seems redundant and hacky. I'm going to be using lots of OS functions and this stuff can help make OS better and fix bugs that have been missed before the new update. As well as help other developers with their programs. :)
I'm not sure what you're doing wrong exactly. For starters, you shouldn't put your forge code directly in the input update function.
Second, you need to filter what sorts of objects you can select. Projectiles should NOT be in this filter. Back when we had the gravity gun I once held on to a rocket I shot, then let it go. When it collided, the game would crash.
Third, whenever you move a object you need to disconnect it from the bsp, then when you're finished you have to reconnect it. The next release will have the required functions needed perform said operations. Internally, the object-set-position function that is also declared in EngineFunctions calls the bsp connection code, so if you were using the engine function you wouldn't have to worry about it. However, you're directly modifying the object's world data so you wouldn't be calling the object-set-position and thus would have to explicitly call the connection code.
I don't think we used any of the mouse buttons for the gravity gun (Internally is was referred to as the ObjectInterface, but kept the name used in gary's mod so users would get the idea) except for Button3 plus the scroller if it has one. For selection toggling we used a key binding.
Thank you for that info! The reason I put the code in there, is because I wanted to catch the button / key states before Halo checks them and does its thing. I didn't want random things happening, like my weapon firing while moving objects at the same time. I guess remapping the mouse buttons while forge is on will work better. Then I don't need to run code in the update function. How should I run forge code? In it's own thread maybe?
Also thanks for the bsp tip, I was using SetPosition, but I took out all the engine functions because it was crashing and I have no idea why. I will revert back to them and figure it out. Also with SetPosition engine function, are physics still working as I move it, kind of like a rag doll effect? A demostration of gravity gun would be sweet and give me some ideas for coding this.
And LOL, this exact same thing happened to me too! haha it's super fun though, especially tossing other players around the map and grenades you can grab out of the air and toss back at them! hahahaQuote:
Originally Posted by Kornman00
Edit: Another question, at the end of object data structs, there is an array of structs that have floats. The number of these structs seems to match the model node / marker count. I had them defined as so from research long ago:
I named it a transform matrix because I didn't know what else to call it. They're unit vectors. Do you know what these are and will you be adding them into the new update?Code:struct ModelNode
{
float Scale;
float Transform[3][3];
float World[3];
};
For my Grav Gun I used the middle mouse button and it worked quite well. Thanks for the disconnect info though...would have helped a lot back then :P
I mean that you shouldn't be placing the forge code directly in the Input Update. Instead, you should be calling Forge's update function from there. Then it decides if and what it can update depending on the game state.
I forget if they're on youtube or not, but I have videos of the old grav gun here and here.
I forget if this is in the last OS's code release, but in the current I have the object's node matrix (the real numbers you're seeing) documented. They're an array of real_matrix4x3.
Halo no longer renders anything with OS.
I updated my graphics card driver for my laptop (Mobile Intel® 4 Series Express Chipset Family) from the Intel website today. I am running Windows 7 64 bit. After I installed it everything was ok. Later on during the night I did some more testing on Forge and the background of the main menu (the Halo Ring) was not rendering and was completely black, although I could see the menu options. When I go into a game, the world isn't rendering(its all white), but the HUD renders.
When I delete d3d9 from my Halo folder, Halo works and renders fine.
I reinstalled Halo, still didn't work.
Next, I uninstalled the driver from the device manager and then with my laptops recovery manager, I installed the original driver. Same effect.
Next, I downloaded a fresh copy of OpenSauce, compiled without any added code, and didn't work.
Just out of curiosity, I downloaded and tried your pre-compiled dll, instead of compiling it myself. It worked.
What the hell is going on? I have changed nothing in my compiler, code, settings or anything. A fresh source compile did not even work.
That sounds like the FOV bug that was present in the original releases. Try going into a game and changing your FOV using the F7 menu, and don't use vidmode, I think that was causing a FOV issue aswell.