Messages

16

Modification Help / Re: Image slot 1 items failing to animate

« on: December 18, 2017, 09:50:36 PM »

Oh, that's just rhetoric... I meant to illustrate the contradiction of the akimbo guns working fine despite the glitch I just described. They use the stateFire thing, which is why I brought them up! :P

17

Modification Help / Re: Image slot 1 items failing to animate

« on: December 18, 2017, 09:05:43 PM »

I did some more looking and the reason it breaks is pretty dumb. I said both altTrigger and setImageTrigger will do the same thing as far as the server is concerned, but it turns out the way the game orders events it will cause setImageTrigger to execute before player trigger processing executes. So you can try and set trigger 1 to on, and the server will treat it just like the player sent the input, but input processing will cuck it back to off later in the same tick... lol

BUT that doesn't explain why the akimbo guns work just fine. There's also a state field called stateFire[n] that has to be true for the firing animation state, with that set setImageTrigger will still go through the motion of being set back to whatever the client has it, however there's something left over that is still sent to the client that will actuate the state change in a different way. This means stateFire[2] = true should fix it.

The whole image state system seems pretty slapped together/concrete so I'm not surprised there turns out to be a billion ways to do a specific thing that work just fine abstract... it's pretty disappointing how limited it turned out despite what looks like an attempt to add cool functionality to certain weapon states.

OH, and you have stateTransitionOnTriggerDown[0] where you define all the info that otherwise uses [2].

18

Modification Help / Re: Workaround for inaccurate vectors on mounted player vehicles?

« on: December 17, 2017, 11:27:49 PM »

It's a visual error thanks to the compression of exact angles for players when their transform is sent from the server. You can see it in action by going third person and switching between the driver and passenger seat in a rowboat at inexact angles.

Ok, quick rundown on why it happens:

1. Driver of bot has their control object set to it so their client performs prediction on it, so the angles they see are exact based on their input.
2. Change of angles are sent to the server, this is relatively unaffected by compression (it's a delta) so the server replicates the exact transform. Both the driver and the server know the "correct" transform of the boat.
3. Server needs to update everyone on what the boat looks like now. It will compress the boat's angles and everyone sees the boat slightly offset because of this. The driver does not get this update since they're predicting it anyways.
4. Driver switches seats. They aren't predicting the boat anymore since their control object is back to their player. The server sends the compressed angles to the ex-driver and he observes it "shifting," so now he sees what everyone else does.
5. Say the driver switches back without the boat changing... the old "correct" angles he had before the server crapped them up are still stored for prediction purposes, so he will see the boat snap back to the correct transform. This means only the server and the most recent driver or whatever changed the boats orientation know the correct angles, but even the driver won't see them if they aren't driving.
6. Anything that needs the transform of mounted objects will just use what the server knows. So when a tank turret is fired, a gun shot, etc. only the driver will have the correct visuals.

Annoying to fix since it's a client issue. I guess with every update the server gets, determine what the crapified transform would be, then for anything that needs to be visually correct feed it the vectors that come from that. That means emulating the angle rounding and re-calculating every mount... a clever way to get the info would be temporarily setting the transform, grabbing whatever, and restoring. Keep in mind this will force a position update so only do it when it's really needed.

19

Modification Help / Re: Image slot 1 items failing to animate

« on: December 17, 2017, 09:09:33 PM »

Be careful when using altTrigger(x) because if you call it with x = 1, then the trigger is "always" activated and will not cause a change in state until it sees a change from 0 to 1 again. Just like how repeating mouseFire(1) doesn't make you click more. I can see the potential mistake where entering altTrigger(1) makes it work, then entering player.setImageTrigger(1, 1) and observing it not working or the opposite effect of (1, 0) triggering it. Not that you did that or anything, I guess it's just a warning for anyone else reading.

There doesn't appear to be a difference whether altTrigger or setImageTrigger is used, as the server will just call the latter function when it gets the signal. There also isn't client sided image code that requires altTrigger to be used to "replicate" the state change visually and cause the animation, or the akimbo guns wouldn't work either. (Funny to think client sided weapon prediction is just a couple if statements away, though!)

If the animation names are all the same, try swapping out the model for the pistol dts the gun uses and see if the same thing happens. At least then you can narrow it down to some weird model error. An easier thing to do might be replicating the states in the akimbo addon and see where the left hand gun stops working, if anything..

Did you manually call setImageTrigger, ie fcbn(name).player.setImageTrigger(1, 1); ? (and getImageTrigger(1) was 0 before?) In the same environment you tried altTrigger in. Now that would 100% make no sense.

20

Modification Help / Re: Image slot 1 items failing to animate

« on: December 17, 2017, 07:35:35 PM »

altTrigger(x) is just a client-sided function to set $mvTriggerCount1 to whatever you give it, so it's part of the move handling system. It is just like crouch(x) or mousefire(x), in this case it's equivalent to setImageTrigger(1, x) when the input reaches the server, and you probably know this is how the akimbo guns trigger the left hand gun to fire. So I only said it to help trigger the weapon directly and avoid anything else potentially getting in the way, I should have just said it was for debugging :P

It doesn't make sense for the animation to activate in slot 0 and not slot 1 if the state is transitioned. How do you know that the fire state works? If everything else like flash, smoke, etc works then you know it is... try the altTrigger(x) thing and see the left hand image's ::onFire is specifically being called, or whatever you set stateScript[n] to.

21

Modification Help / Re: Image slot 1 items failing to animate

« on: December 17, 2017, 06:44:21 PM »

If it's a player animation, you might be playing the wrong thread name (leftRecoil for left hand, shiftAway for right). If you're playing two different animations "at once" like you said, then they won't work simultaneously on the same slot (first argument of playThread) But if the names are right, then the fact it works fine in slot 0 makes me think you don't use a player animation unless you have code that can differentiate what hand the image is in. And the fact that playing them at the same time should make the right hand not fire if it's made the way I think it is.

So if it's an image animation, it will be triggered through the state system and not the scripted part specifically, with stateSequence[n] = "..." and should work so long as the state is executed which you made it sound like it does. If all that fails then toy around with the akimbo gun item, I know the left hand gun has an image animation AND a player animation that both work so it should help you solve either problem. Protip: altTrigger(1 or 0);

22

General Discussion / Re: "Ana" ARG thread

« on: November 14, 2017, 06:13:11 PM »

I checked the linker time of the mike DLL in the PE header and it says Nov 9 21:26, so that means it was likely created for this purpose.

23

General Discussion / Re: Shadows not working... with a 4GB AMD GPU?

« on: November 14, 2017, 10:15:17 AM »

The Mac rendering support is flimsy at best, there's not even an implementation for vbos which is like a basic requirement for block games now. It's just how it worked out for library support at the time, and it follows that shader support isn't there.

If you need a solution, you can try setting up a dual boot system and install either Linux or windows on a different partition. I don't know the exact steps to retain OSX but a quick Google search makes it look like it's easy.

24

General Discussion / Re: "Ana" ARG thread

« on: November 13, 2017, 08:30:40 PM »

Then it's spookier because the mike DLL randomly showed up. Maybe it's just a regular ol' DLL someone made and Ana uploaded it for no reason, and then when asked for the source they posted it as their own project later. IDK, someone answer the request I had because it's hard to draw conclusions from deleted threads. The record needs to be corrected (tm).

25

General Discussion / Re: "Ana" ARG thread

« on: November 13, 2017, 08:08:05 PM »

i dont know where your friend got "zodlrm.dll" because thats not the DLL

the proper DLL should just be DiscordDLL.dll

YEA, I thought the name was weird too. I had three guesses:

- it was shared around using some kind of hosting service that mangled the name
- the name is spooky or is a clue because it fits the ARG theme
- some guy was testing this against their own build and put two DiscordDLL.dll in the same folder for some reason, so they slapped the keyboard to lazily resolve the name conflict and later shared it around (meme)

I decided to just put that side note in because the contents of the DLL check out against the github source, ie strings, order of execution, and so on, and I then might get some insight later (AND IT TOTALLY WORKED!1)-- I didn't get to see the original thread/"release" so the question of the name's roots or how seriously I should take it was out the window. It made sense an ARG would name files like this; innocent me slapped it into ida and happily chugged along at decoding the ancient mythological secret doomsday DLL the alien name implied.

That is in the past. I now have investigated this and... Val regrets to inform you it was the first thought: someone uploaded it to my friend using mymixtape and then he later gave that to me in all its mangled glory. I had no idea this stupid site existed (i live under a rock) and figured six lowercase characters for entropy would be dumb for a file sharing service, and one that changes file names at that. like WTF. I ended up giving way too much benefit of the doubt to the third idea and looked like an idiot. I wouldn't have done this anywhere else but in an ARG thread and yet here we are.. val_JUST.png and I'm 3000% mad.

OK, sorry for writing this much for a non-problem but I thought sharing my epic fail would make someone laugh at with me. But yes, it is the real deal.

whats your source for this because theres literally nothing like this in the DLL from ana's github release 3 days ago

im looking in the DLL from github 3 days ago not the source

post the DLL you're talking about that says "mike" in it

It's the debug file path that's compiled into the binary. Try searching "mike" in a hex editor or something.

That string actually comes from the DLL they supplied rather than the source. The one that says mike.

That's what I said. The supplied DLL and source are supposed to match 1:1, but if that's the case then mike wouldn't show up in the DLL, and the source is crafted to make you believe in the 1:1. You are supposed to say "wow, great moves detective val" and be impressed.

Or maybe val_JUST2.png is on it's way and you're saying Ana did not supply the mike DLL. I kind of just jumped in when DLL was mentioned. OK, someone give me a quick rundown on how it came to be before I write myself into irrelevance. I'm just here to reverse spooky DLLs.

26

Drama / Re: chakada's key has possibly been stolen

« on: November 13, 2017, 12:42:10 AM »

I'm flattered but I pinky promise this is not me. I never used glass before, at least not in the past 3 years. :P

imagine being above 14 years of age and spending almost 5 years of your life actively developing a hack for a lego game

Jokes on you, the first one was made when I was 13 :D

27

General Discussion / Re: "Ana" ARG thread

« on: November 13, 2017, 12:24:04 AM »

Ok, a friend gave me the DLL Ana made (it's called zodlrm.dll.. I hope that's it!) and I found time to look at it in ida. It's not packed or encrypted, and there's no real difference from the source as far as the initialization routine goes. It's funny to see player collision toggle DLL strings here and there, which supports the idea it's rather crudely made (this is in the source too). The only DLL of importance in the IAT is the runtime and I don't see any evidence of LoadLibrary calls. So at the surface level it appears pretty safe, except for the fact the RPC library is statically linked. It's fine to do that but it has some security implications...

The discord RPC library is open source so it can be compiled with any modification and later static linked to the binder DLL. It would be very easy to sneak in malicious code when the size of the library is as big as it is, and I really don't want to spend hours digging through all that crap to find something either. It would have been more legitimate if they used RPC as a DLL because then they can't hide anything, but it's another thing to add to the mod folder and it's perfectly valid to static link like this for convenience.

We don't know what configuration they used to build the lib either, so that could explain the size difference mctwist is getting, like if they used optimizations or they turned off certain features that made it smaller, and potentially a bunch of other things. I wouldn't think a newer version would cause a size difference that drastic unless there was some major feature added, so check the github page I guess. To get a better answer he'd have to tell us the config he used to build the libraries... I'm not gonna bother experimenting myself for now because I'm too lazy to get the v140 toolset. :P

But if this is a puzzle that isn't supposed to be super hard, and there's clues knocking around in the DLL, then they'd probably expose it in a way that doesn't require much beyond tools like wireshark, hex editors or process monitor, and of course making it malicious invalidates the whole ARG. A memory editor is a good idea too in case there are strings that are decrypted at runtime. But I doubt there's much more to discover besides that one string...

It was mentioned before: there exists an interesting string which happens to be the program database, "c:\users\mike\documents\visual studio 2017\Projects\DiscordDLL\Release\DiscordDLL.pdb." The purpose of one of these is to provide useful debugging information (symbols, links to source, etc) to whatever needs it, but the database itself is not very important. What's weird is the project settings in the github do not explicitly state a path like this, and if one isn't defined it defaults to the location of where the DLL is written to. So Anneliese didn't build the DLL themselves according to the project settings in the github, some guy named mike did and the config was pruned to make it look like Anneliese built it when the source came out.

tl;dr it's probably safe except the fact there could be code hidden in the static linked RPC library, we don't know the config they used to compile RPC and this affects size, and the debug database path doesn't match the source code which means someone else named mike built it.

28

Help / Re: Runtime Error on some servers.

« on: November 12, 2017, 04:07:32 PM »

Try updating your drivers I guess: https://downloadcenter.intel.com/product/81503/Intel-HD-Graphics-for-Previous-Generation-Intel-Processors

29

Help / Re: Runtime Error on some servers.

« on: November 12, 2017, 03:02:43 PM »

Does it just happen randomly? It's really too bad the runtime errors are so descriptive. What GPU do you use?

30

General Discussion / Re: "Ana" ARG thread

« on: November 12, 2017, 10:31:26 AM »

Then they would include the DiscordRPC dll in addition to the binder dll, or require it to be installed somewhere that blockland can load it (ie installation or placing at the root directory or similar) Static linking is configured in the settings for the rpc library anyways. There is no reason the header would increase the size unless there's something really stupid in there..

What you should do is check the dll with a packer identifier. If nothing shows up then investigate the code in ollydbg and see if it's a custom packer or if the instructions are radically different (compare entry points and their functions to a certain depth), Ida works great for this too. Evidence for packers like if there's no IAT or a bunch of garbage data for most of the dll should be checked too. Try comparing their size in-memory.

Edit: I accidentally said the settings dynamically linked RPC but I totally meant static in context ("not dynamic".. forgot the not :P). Sorry for the confusion.. it was early.