What are you working on? January 2012

[danharibo]

[QUOTE=Darwin226;34246262]Since the depth can't really be negative, is there really need for null?[/QUOTE]

That's another way to do it yes.

[thomasfn]

[QUOTE=esalaka;34246060]That's interesting syntactic sugar.

[editline]16th January 2012[/editline]

Can't see why double would need to be nullable, though.[/QUOTE]

I guess it returns the intersection depth. 0 = touching, null = no intersection.

[b]Edit:[/b]
I should really refresh the page more often..

[neos300]

Thanks.

Attempting to make a binary heap to make a* faster, but the fact that type* w/e = new type[100] creates an array of references is annoying because they may need to be null.

[acpm]

[img]http://img46.imageshack.us/img46/3858/administratorcwindowssy.png[/img]

IT BEGINS.

[esalaka]

Why don't we have one of those thread simulator videos

there's probably enough drama in here to warrant one

[acpm]

"synthiac should synthiac synthiac"

"i would like to hug a yogurt non-sexually"

[swift and shift]

[QUOTE=neos300;34242525]Ha. Changing my containers to be std::vector<Sphere> (derived type) - no problem
std::vector<Shape> (the base type) NO FUCK YOU
Or anything else really, I've tried references, pointers, you name it.[/QUOTE]

you can't put references in an stl container

[editline]17th January 2012[/editline]

because then you'd have methods returning a reference to a reference

[Legend286]

[QUOTE=raBBish;34234109]Couple small updates before I go to sleep.

...[/QUOTE]

What I'm wondering is how you're doing this without triggering VAC.

[neos300]

[QUOTE=sondre99v;34245143]This one is quite neat, although personally I found it slightly hard to follow:
[url]http://www.siggraph.org/education/materials/HyperGraph/raytrace/rtinter3.htm[/url]

Here is an implemented method in C#:
[url]http://pastebin.com/KisLS90K[/url]
Use at free will[/QUOTE]

I'm assuming this is a method for a ray, but can I see the code for your bounding box class?
I'm not sure what Min and Max are (the members for the bounding box - are they the corners?)

[Nexus435]

[QUOTE=Legend286;34248219]What I'm wondering is how you're doing this without triggering VAC.[/QUOTE]

We've had this discussion before, go read up on VAC.

[Legend286]

[QUOTE=Nexus435;34248523]We've had this discussion before, go read up on VAC.[/QUOTE]

I always thought tampering at all would result in a ban, whether it was for cheats or not. I guess they aren't lying when they say it "detects cheats" and only cheats... :v:

[boomer]

[vid]http://dl.dropbox.com/u/2276133/Terrain01%202012-01-16%2018-38-01-93.webmvp8.webm[/vid]

[pollyzoid]

Continuing with the frustrating bugs [img]http://www.facepunch.com/fp/emoot/smithicide.gif[/img] e: Whoa, a big wall this time.

This is a subject I've been avoiding for a while, since I knew what pains await there. But I still went ahead and hooked CreateMove. For those who don't know, CreateMove and couple others prepare User Commands from the client's input and send them to server. It contains stuff like buttons pressed, move directions (forward, side and up) and view angles. Orange Box update changed them to require verification; with the old method we could just modify the CUserCmd, but OB added couple new steps.

This is a simple CreateMove hook, works with OB games:
[cpp]void
hooks::client_dll::CreateMove(int sequence, float frametime, bool active)
{
g_client_dll->vmt_.get<CreateMove_fn>(idx_CM)(g_client_dll->inst_, sequence, frametime, active);

IInput *inp = source::g_interfaces->Input;

CUserCmd *cmd = inp->GetUserCmd(sequence);
CVerifiedUserCmd *v_cmd = *reinterpret_cast<CVerifiedUserCmd**>((intptr_t)inp + 0xB8) + (sequence % 90);

if (cmd)
{
cmd->forwardmove = 400.0f;

v_cmd->m_cmd = *cmd;
v_cmd->m_crc = v_cmd->m_cmd.GetChecksum();
}
}[/cpp]

IInput->GetUserCmd simply returns the specified CUserCmd from an array. CVerifiedUserCmd was the new addition in OB, and there's no public way to retrieve one of them. So we use an offset found by disassembling and get the command through that. The lines after setting forwardmove are another new addition. CVerifiedUserCmd is a class containing just a plain CUserCmd and a CRC32 value, which is calculated with CUserCmd::GetChecksum. The example just makes the player move forward constantly.

However, there's a complication. This doesn't work for GMod. LuaStoned has tried as well, he only got null CUserCmds from GetUserCmd. That was my problem initially, but I improved it with a small change, by using the same method for retrieving the CUserCmd as CVerifiedUserCmd.

[cpp]CUserCmd *cmd = *reinterpret_cast<CUserCmd**>((intptr_t)inp + off_UCMD)
+ (sequence % 90);
CVerifiedUserCmd *v_cmd = *reinterpret_cast<CVerifiedUserCmd**>((intptr_t)inp + off_vUCMD)
+ (sequence % 90);
[/cpp]
off_UCMD and off_vUCMD are the offsets to the arrays, 0xB4 and 0xB8 respectively. This worked in GMod... kind of. For some reason every second tick of CreateMove would have an invalid usercmd, where the command id and tick count would be zero, with rest of the members being null or garbage. There was something strange going on. I decided to dig up IDA again and check out the disassembly.

TF2 version of GetUserCmd:
[cpp]int __thiscall CInput__GetUserCmd(int this, signed int a2)
{
int v3; // eax@1

v3 = *(_DWORD *)(this + 180) + (a2 % 90 << 6);
return ((*(_DWORD *)(v3 + 4) != a2) - 1) & v3;
}[/cpp]

Same but GMod:
[cpp]int __thiscall sub_100EA780(int this, signed int a2)
{
int v3; // eax@1

v3 = *(_DWORD *)(this + 180) + (a2 % 90 << 7);
return ((*(_DWORD *)(v3 + 4) != a2) - 1) & v3;
}[/cpp]

There is a very subtle difference, but I hadn't paid any attention to it before. I copied the first line as-is and tested the hook again. This time it returned all valid commands, no strange skipping. However, when trying to verify the command, GMod would crash after a few ticks. Another user on a forum had found this same problem, but the thread was unhelpful at best. Nobody seemed to know why it crashed, instead suggesting to use GLua.
I didn't give up that easily. There was a difference in the verified commands that was causing problems. I dug deeper into Source and found CInput::CreateMove. This method creates/resets the CUserCmd and passes it on.

TF2:
[cpp]_EDI = *(_DWORD *)(LODWORD(a2) + 180) + (a3 % 90 << 6); // This is CUserCmd
v53 = *(_DWORD *)(LODWORD(a2) + 184) + 68 * a3 % 90; // CVerifiedUserCmd?[/cpp]

GMod:
[cpp]_EDI = *(_DWORD *)(LODWORD(a2) + 180) + (a3 % 90 << 7);
v56 = *(_DWORD *)(LODWORD(a2) + 184) + 132 * a3 % 90;[/cpp]

You can see the same difference here, 7 instead of 6. The array offsets are also visible, 180 and 184 (0xB4 and 0xB8). However, there was another difference in CVerifiedUserCmd. 68 turned into 132. I scrolled down, noticed that GMod's initialization list was longer than that of TF2. Then it hit me. GMod's CUserCmd and CVerifiedUserCmd were bigger than the OB ones! I started going through the list and checking that garry hadn't moved anything. He only added stuff at the end, good. I copied over the line for getting CVerifiedUserCmd and tested it in GMod. Wonderful, it actually worked! However, GMod crashed on exit and I really hate when that happens. I figured it was because the classes I used were the wrong size. I created a GMod version of CUserCmd and started counting variables and their sizes, padding the class where it needed it.
While padding, I also figured out the magic numbers. 1 << 6 = 64, 1 << 7 = 128. If you look at the number on the line for CVerifiedUserCmd, they're 68 and 132. Both had 4 bytes to spare. So the left shift is for CUserCmd size, then CVerifiedUserCmd is +4 to that, since CRC32 takes 4 bytes. So the numbers were for marking the size of the classes. At this point I made a change in my Lua config and added the user command size.
[lua]UserCmdSize = GAME == "garrysmod" and 7 or 6[/lua]

When I had the padding right and the members' offsets matched with disassembly, I fired up GMod to try. Still worked in-game, but crashed again on exit. I started commenting stuff out to test what exactly causes the crash. First the whole CreateMove hook, crashes. Modifying CUserCmd, crashes. Then I left only the verification commented. Still crashes. As my last effort, I left only the line for calculating CRC commented. I went in-game and the first thing I noticed was that I was moving. I was moving without having to actually verify the usercmd. Then I exited the game. I didn't crash. What the fuck. GMod doesn't actually check the CRC. Reason it crashed? I don't know. Maybe it doesn't expect the CRC to be there and doesn't remove it, leaking memory?

Here's the revised test code.
[cpp]void
hooks::client_dll::CreateMove(int sequence, float frametime, bool active)
{
g_client_dll->vmt_.get<CreateMove_fn>(idx_CM)(g_client_dll->inst_, sequence, frametime, active);

IInput *inp = source::g_interfaces->Input;

CUserCmd *cmd = reinterpret_cast<CUserCmd*>(
*(DWORD*)((intptr_t)inp + off_UCMD) + (1 << size_UCMD) * (sequence % 90));
CVerifiedUserCmd *v_cmd = reinterpret_cast<CVerifiedUserCmd*>(
*(DWORD*)((intptr_t)inp + off_vUCMD) + ((1 << size_UCMD) + 4) * (sequence % 90));

if (cmd)
{
cmd->forwardmove = 400.0f;

v_cmd->m_cmd = *cmd;
if (size_UCMD != 7)
v_cmd->m_crc = v_cmd->m_cmd.GetChecksum();
}
}[/cpp]

If you notice, I'm not actually using the padded classes anywhere. Well, they weren't actually needed. The only reason it was crashing on exit was because of the CRC.

[b]tl;dr:[/b] GAARRRRYYYY [img]http://www.facepunch.com/fp/emoot/unsmigghh.gif[/img]

[QUOTE=Legend286;34248219]What I'm wondering is how you're doing this without triggering VAC.[/QUOTE]

VAC doesn't scan data sections, where the vtable pointers are. So we can switch them around with VMT hooks without worries (for now). Traditional detours can't be used, since they work by inserting a JMP into the target function, editing .code section and possibly triggering VAC. However, this limits us to only being able to hook virtual methods. Anything else is out of limits.

[Hayburner]

[QUOTE=raBBish;34249326]stuff[/QUOTE]

an easier route than hooking CreateMove would be to hook IVEngineClient::SetViewAngles, check if the return address points to CInput::CreateMove, then grab CUserCmd pointer off the stack (should be stored in ESI register). SetViewAngles gets called in CInput::CreateMove, which in turn gets called in IBaseClientDLL::CreateMove... bingo. only thing to worry about is possible stack corruption issues and the fact that random_seed isnt set yet so you must set it yourself via MD5_PseudoRandom(). when all is said and done you don't need to deal with all that verification bullshit.

[icantread49]

-saving for later-

[acpm]

the consistency of that blue stuff reminds me of applesauce

[BlkDucky]

when he said that his apps were going to be revolutionary, I didn't think he literally meant things were going to spin

[icantread49]

-saving for later-

[supersnail11]

*cough* phyzios studio *cough* is free *cough* and has the same features *cough*
Sorry null, looks like i've got a cold.

[icantread49]

[QUOTE=supersnail11;34250636]*cough* phyzios studio *cough* is free *cough* and has the same features *cough*
Sorry null, looks like i've got a cold.[/QUOTE]

*opens up phyzios studio*

*confirms phyzios studio is [b]entirely particle-based[/b] and contains [b]no rigid body dynamics with constraints[/b] like motors*

not to mention the awful interpolation between different types of particles

[naelstrof]

Issac, your air is running low. MuhAHaha
[vid]http://j.mp/z1746a[/vid]
Got animations working properly; it's really easy for users to mod too. Textures are loaded from text files like this one (I didn't use json or xml don't hurt me please):
textures/human/human:

anim idle 1fps {
	textures/human/human_idle000.png
	textures/human/human_idle001.png
}

anim walk 5fps {
	textures/human/human_walk000.png
	textures/human/human_walk001.png
}

anim idle_choking 2fps {
	textures/human/human_choking_idle000.png
	textures/human/human_choking_idle001.png
}

anim walk_choking 5fps {
	textures/human/human_choking_walk000.png
	textures/human/human_choking_walk001.png
}

Now to expand on the player class until it can die from blood loss, suffocation, concussions, dehydration, and hunger. With appropriate death animations for each!

[robmaister12]

I've gotten so frustrated at GDI+ for not exposing a lot of the API in C# that I decided to work on FreeType bindings. I know that there's the Tao FreeType bindings, but they're incomplete, severely outdated, and look more like the original C API than a C# library.

I'm building the bindings off the Tao ones, but made to look like OpenTK's bindings, ie this:

[cpp]FT_EXPORT( FT_Error )
FT_Init_FreeType( FT_Library *alibrary );[/cpp]

becomes

[csharp]FT.InitFreeType(out IntPtr alibrary);[/csharp]

(I actually have no idea how I should handle things like "typedef struct FT_LIBRARYREC_ *FT_LIBRARY" so I'm just using an IntPtr for now)

If anyone's interested, I'll split the code off into a separate project, MIT license it, and host it on GitHub.

[neos300]

Cool, got ray tracing boxes written, not sure if I correctly defined the bounding box or not let's see if it wor-
[img]http://img37.imageshack.us/img37/2197/screenshot2012011621113.png[/img]
NOPE

Code if anyone cares: [url]http://pastebin.com/yDhfgSg5[/url]
I'm going to bed soon, so don't bother asking for more info if you aren't going to ask in the next 5 minutes.

[supersnail11]

[QUOTE=icantread49;34250687]*opens up phyzios studio*

*confirms phyzios studio is [b]entirely particle-based[/b] and contains [b]no rigid body dynamics with constraints[/b] like motors*

not to mention the awful interpolation between different types of particles[/QUOTE]

you're not playing the same one i am

because mine has rigid bodies with constraints

[icantread49]

[QUOTE=supersnail11;34251229]you're not playing the same one i am

because mine has rigid bodies with constraints[/QUOTE]

i think you missed the "for iOS and Android" part

[supersnail11]

[QUOTE=icantread49;34251281]i think you missed the "for iOS and Android" part[/QUOTE]

let me find that screen recorder for ipods and i'll get back to you

[icantread49]

[QUOTE=supersnail11;34251334]let me find that screen recorder for ipods and i'll get back to you[/QUOTE]

screen recorder for ipods :v:

look, the proof is simple: go to app store, type in "phyzios studio", the only version you'll find is the one i described ... you're clearly wrong

[editline]17th January 2012[/editline]

and if you're so intent on proving it, press the home button & lock button at the same time to take a screenshot of the app's icon and then the app itself

[supersnail11]

[QUOTE=icantread49;34251466]screen recorder for ipods :v:[/QUOTE]

Yes, it's called "ScreenRecorder", and it costs $1.99 on cydia. But I don't really feel like paying for that, so here's a screenshot.

[img]http://dl.dropbox.com/u/23280705/hinull.png[/img]

[icantread49]

good job, you took a screenshot of the exact same app i was describing

thanks for the proof that phyzios studio is [b]entirely particle based[/b]

those aren't rigid bodies, those are particles with forces to counteract any deformation ... and notice the poor interpolation between different materials

but, hey, let's take a step back and pretend like those are actual rigid body dynamics: where are the springs, rods, motors, elasticity/density/friction settings, multi-touch scaling/rotation/translation interactions, and so on?

[supersnail11]

[QUOTE=icantread49;34251811]
those aren't rigid bodies, those are particles with forces to counteract any deformation[/QUOTE]

[quote=Wikipedia]
In physics, a rigid body is an idealization of a solid body of finite size in which deformation is neglected.
[/quote]
[quote]
deformation is neglected.
[/quote]
i see no problem here