Printable View
Wish i could. There is no exception data to post, unless ya mean the debug.log file. The program used to crash until I did a system restore. I even got rid of CE and reinstalled it, thinking that would help fix it, so it's working fine now. It was definitely something that Live Essentials installed.
I saw stuff like Visual Studio Runtime files, Sync Runtime, and a bunch of other crap that was installed.
Edit: No, OS_Tool didn't exception. It ran just fine.
Vista has a "Errors and Reports" section (or something to that name) in the control panel. If there was a problem inside the tools themselves, they would have entries in that. Unless the restore cleared the data.Quote:
Originally Posted by Rambo
Yeah it probably did clear it.
I'm not worried about it now like I was.
The only reason I'm still thinking of it is just a curiosity factor. Does your thing use Visual C++ 2005/2008 runtimes? If it uses C++ then perhaps Live Essentials screwed it up by installing conflicting C++ runtimes with the latet.
Yeah, the HEK uses the 2003 and my extensions use the 2008 runtimes. However, unless LE fuged the actual DLL code I don't think the runtimes were the problems. But it's over now
Fire/Rambo will you be available for contact on the 12th thru the 15th?
I should be, yes. 14th possibly not.
If you need, i can help too.
Absolutely!
Might have a small cheApe bug here, the version field doesn't get set to its intended value by guerilla when a new tag is created. For instance my shader collection tag has this:
...and always has version 1 when created by guerilla. But the os bitmap tag:Code:<TagGroup name="shader_post_process_collection" groupTag="shpc" version="1">
<field type="ShortInteger" name="version" locked="true" />
<field type="Pad" definition="2" />
...has version 0.Code:<TagGroup name="os_bitmap" groupTag="osbm" version="1">
<field type="ShortInteger" name="version" locked="true" />
<field type="Pad" definition="2" />
Also, whats the field type name for real argb color? I've tried a number of variations but can't find the right one :saddowns:.
I actually had to write code to fill the version fields in the tags included in the OS SDK, it's not a "feature". This was just to make sure that versioning information is stored even when building a cache file.
It is probably RealRgbaColor. Or RealArgbColor. I don't have access to the source ATM
I hate to say it but I'm basically 2 classes through with C++ (into to and OOP) and I'm still having trouble making heads or tails of most code. You sir, are very advanced.
Don't always assume that what looks advance and magic super sauce...
...is magic super sauce :P. Some of it may be, but the code base could really do with some refractoring and some changes so everything is following a set standard (ie, naming conventions; I've broken this in a few areas). Thanks for the complement though :)
No prob. I'd really like to learn how you figured out how to do most of this and how it works. I have a pretty solid C++ foundation but I'm not really experienced in reverse engineering. Any books, or ebooks you'd recommend?
Go crack some stuff..it's the best way to get into reverse engineering (motivation etc).Quote:
Originally Posted by SMASH
I'll PM you a vid tut
Abstraction layer go! -I think that if you had organized OS by the 'levels' of code, it would be more understandable.Quote:
Originally Posted by Kornman00
Um, Korn... If you're working on the OS HEK side still, I found a nasty bug that can get very annoying left over from your Kornman00 v2.0 build.
Whenever I do shortcuts, such as CREL+C or CTRL+V or even delete a file with the DEL key, OS_Sapien and even OS_Guerilla crashes saying an exception occurred and the program has to shut down. This can be very annoying for people that want to do so much as clean up a folder by deleting files. We have to use regular Sapien to do this or Guerilla, or go in manually visa Windows Explorer and delete old files.
It's kind of bothersome and I'd like to see it fixed. Any idea what the causal source of the crash might be?
EDIT: This is a bug report video i created to demonstrate exactly what Open Sauce HEK is complaining about. Please download and watch and, if necessary, keep for archival purposes until you fix the bug.
^ Doesn't happen to me.
You're saying if you copy/paste a file/folder in the open file dialog in guerilla and sapien, they exception?
Nero is causing the problem I guess. It's farked.
Or maybe it's a dependency. Let me try and remove it and see what happens.
Can't download the video ATM, will try when I have access to my computer
While in most cases I would agree with that assessment, when it comes to "hacks" such as this, I don't try to go too far beyond what the engine already provides.Quote:
Originally Posted by Dwood
1) Debugging is a PitA since you have to launch black box software which provides you with no debug data on crashes besides generic exception data.
2) Introducing more complex and tricky code breaks away from the model I use when creating these hacks: deterministic compilation. A model I made up, basically any code that I create doesn't or shouldn't result in behind-the-scenes constructs such as at-startup or at-exit procedures created by the compiler. It's also needed when building pure assembly interfaces with engine code. I need to know exactly how my code will compile.
3) Almost every component deals directly with a 1:1 engine system. These systems themselves have their own abstractions however there is very little access to them besides what I've uncovered and documented in EngineFunctions.cpp. In order to make sure there aren't any conflicting designs or functionality, I kept with structures and interfaces which the game code itself has, just as if I was extending the actual source. Of course this requires a mixture of low level access and constructs. These are unavoidable
4) Footprint. I didn't want this game extension putting any sort of extra footprint on the game. Thus, most additions result in O(1) operations since everything is predetermined and preallocated, with no extra information being tracked and handled besides what the game already gives you (or rather, what you take).
Different problems call for different solutions. Not always will you use an OO framework for something. You could end up with a procedural construct instead for whatever problem. If I had actual engine source this codebase would be FAR different in implementation. However, the overall code layout/design would stay the same.
this is the field type name, to answer your questionQuote:
Originally Posted by Kornman00
Yeah, forgot to post that that one worked. I was being foiled by capitalisation :gonk:.
In order to make Lightmaps work fully, we need to force Halo CE to bypass the structure_bsp tag embedded in the .scenario tag, as well as the sky tag. In order to use the BSP Sets, we must trick or force OS_Toolbeta into recognizing the project_yellow tag as a scenario_structure_bsp tag. When compiling with no BSP, i got this exception.
As you can see, it DOES recognize that there is a BSP; however, it halts upon detecting that it's coming from the project_yellow tag. I say this because of the fact that it senses my unused clusters, which i set up as a test to deliberately create an error warning that would let me know when a BSP is being used.Quote:
Microsoft Windows [Version 6.0.6002]
Copyright (c) 2006 Microsoft Corporation. All rights reserved.
C:\Program Files\Microsoft Games\Halo Custom Edition>os_toolbeta build-cache-fil
e levels\test\blood_creek_campus\blood_creek_campus
Couldn't read map file './toolbeta.map'
WARNING: 16 clusters in structure_bsp levels\test\blood_creek_campus\blood_creek
_campus have no background sound or sound environment.
EAX: 0xE1740000
EBX: 0x006C8F01
ECX: 0x106BD24B
EDX: 0x006CF740
EDI: 0x00129E30
ESI: 0x00000000
EBP: 0x00129D08
ESP: 0x00129CF8
EIP: 0x776D5E74, C3 8D A4 24 ?????
EXCEPTION halt in \halopc\haloce\source\tag_files\tag_groups.c,#265: tag_get(0xe
1750001) expected group 'scenario_structure_bsp' but got group 'project_yellow'
C:\Program Files\Microsoft Games\Halo Custom Edition>
Please help fix this so we can utilize Lightmaps fully.
I explained to you how it would work Rambo. You're just going to have to wait until I figure out how to do it myself because no one else is going to do it.
I understand. It's just, how are we going to reroute the BSP information from the scenario to the project_yellow tag, forcing an ignore of the data in the .scenario structure hierarchy, including BSP and Skies. As of now, Sapien utilizes the data from the .scenario tag, ignoring the project_yellow information. We would have to encode something into the tag_groups.map, which is the equivalent of the d3d9.dll for Halo CE, which Sapien cannot run but the tag_groups.map it does recognize. Somehow, we have to route scenario functions to the project_yellow side of the equation before we can utilize new cript commands.
That's where Kornman00 comes in, because he can address the HEK issues, not the SDK ones that we can. We don't have his code for the HEK; he does.
Nevertheless, I do understand where you're coming from, Dwood. I agree totally. Yes I do have to wait. Any suggestions on a fix?
BTW: Thanks so much for stepping up to the plate and helping. I know it seems like i may not be appreciative, but I am quite the opposite. I do appreciate the help because without a programmer, my DTS would suck.
Dun worry about any of the hek issuez. When I figure this whole adding tags to Open Sauce I'll add it- I'm not 100% sure if I'll be using that section of the Yelo Tag, however, until I understand all that goes on in that area of OS. I may just be adding my own tag, or use a tag_list (hek not handy).
You're going to have to wait, a while, however. (ie probably at least 3 weeks mang) My priority list has been reshuffled. quite a bit.
Hey I've waited this long I can wait longer.
Run lightmaps in the meantime lol.
1) You got that error because you tried building an OS enabled scenario using the stock build-cache-file command. You can't do that (I'm pretty sure I stated this somewhere). You have to remove the reference to the yellow tag, then you may have to hex edit the scenario tag to change the tag reference field to a 'sbsp' instead of 'yelo'.
2) There's tag data already avaiable in the project yellow tag for filling out lightmap data...just use that. It's just manual work. That's as much support you're going to get from me on this multiple lightmap issue.
where do you hex edit it? At the BSP side or the Yelo side? I mean... Up top at the bottom?
it's the first field in the tag so at the top of the scenario tag file
is there any way to create a branch in OS_Tool where if you have a Yelo tag referenced, it will use that to pull its data, or if you have a BSP tag it'll use that, but not both? That way when you compile it won't exception anymore?
Also, I tried build-cache-file-ex and it still bombs. The weird thing about both scenarioes (build-cache-file and build-cache-file-ex) is that it DOES recognize the BSP tags, because i see it starting to go and reporting errors in the clusters not containing both sound environment and background sound data. Then, the compiler senses the Yelo tag and exceptions, exploding like a bomb.
Hex editing can be a pain in the butt, especially for complete n00bs to hex editors and the likes, such as myself. If we could have a branch in the new tool command where both build-cache-file and build-cache-file-ex detect one or the other but not both, then it would save us all a ton of time.
Furthermore, We'd like to use script functions because they're more versatile, but then there's that stupid crashing error in Sapien with all OS script functions, regardless of their programming. What's going on with that and a possible fix?
Dwood, I know I should wait. I am. I'm just wondering what's up and experimenting with stuff on the side to see what our options are; that's all. I'm also reporting my finds of bugs to Kornman00.
BTW: I'm afraid that if I edit the .scrnario file that it will do the following.
- Not open in either editor
And / Or...
- Bring down the entire HEK when trying to compile in OS_Tool because it's considered foreign and not stock
That's why i'm hesitant to do this.
In order to keep existing scenario tags savvy with OS I had to replace an existing tag field. The "DON'T USE" field which in normal cases expects a structure_bsp reference. Hence, if you try to open the scenario tag in a stock program or use a stock command it's not going to work. Ergo, you'd have to clear the field of the reference name plus IIRC, hex edit the group tag stored in the binary data to be 'sbsp' instead of 'yelo' (again, because in stock tools it expects it to be a structure bsp reference). It's a simple edit of 4 bytes.
Hex editing requires some work yes, but since it's the very first field and at the start of the tag file I really didn't see it as much of a mine field because 1) people shouldn't be mixing their OS enabled scenario tags with a stock pipeline and 2) it is assumed an end user has some level of degree of higher knowledge in these subjects if they're trying to implement something with OS. A hacked-in extension of black box software will almost always require some level of overhead from the end user.
You are making this a lot more complicated than it needs to be, and it doesn't help that you have little to none programming/reverse engineering experience. I did a little testing because I was beginning to get annoyed with you constantly posting about it, and I found it was pretty easy to do this. It took me less than an hour total.Quote:
Originally Posted by Rambo
http://www.youtube.com/watch?v=WTfy4hJainc
http://www.youtube.com/watch?v=BlpS6a_7KdI
I don't want to use the YouTube tags and clutter up this thread even more than it already is. Thanks to Siliconmaster for the test bsp.
whoa that's awesome.
Oh, so that's what you were using that for. And yeah, as soon as I saw the 3 color versions, I envisioned a rave. Needs techno looping music.Quote:
Originally Posted by ShadowSpartan
Well ShadoSpartan you beat me to it, even though that shouldn't surprise me, or you. Did you end up using the method I wanted to use for the switching of lightmaps or did you use another way?
ShadowSpartan, how in the HELL did you get that working? What the ****!!!!!!!!!!!!!!!!!
PLEASE, can I have the tag_groups.map and d3d9.dll? I owe you man.
PM me for E-Mail or Xfire info.
EDIT: I think I know how you did it. You referenced an explicit tag path (i.e. bitmap path) and set that to be the lightmap reference. Does this change sky also? If it doesn't, can you also make a switch_sky command that references a sky so that people can change those along-side the lightmap data? Just wondering. I'm asking nicely; not trying to be annoying.
Again, I want to thank you personally for doing what you did. This means that, on the current BSP, we can use as many lightmaps as we need, never having to switch BSPs.
EDIT 2: I heard from Dwood that the source code and project is about to be released. Any idea when? I would love to get started on working with it so i can script and be out of your hair for quite a long time. I've got a lot of programming and setting up to do for a test day-night system.
Could you at least please E-Mail me the d3d9.dll and the tag_groups.map file, ShadowSpartan? I'm so excited and bored at the same time, it feels like a five-year-old waiting for Christmas. I know the thing works; question is, is it ready for release?
I need the exception data (from the problems and reports page and debug.txt) from sapien when it crashes when trying to compile custom functions.
Be sure you're setting "run_game_scripts" to false before you compile.
OS_Sapien is not showing up on the problems and reports page. Here is the debug.txt entry from when I try to compile.Quote:
Originally Posted by Kornman00
Code:02.11.10 16:42:45 sapien pc 01.00.08.0616 ----------------------------------------------
02.11.10 16:42:45 reference function: _write_to_error_file
02.11.10 16:42:45 reference address: 401b13
02.11.10 16:42:45 Couldn't read map file './sapienbeta.map'
02.11.10 16:42:45 CreateDevice succeeded with refresh rate = 0
02.11.10 16:42:46 Sound card doesn't meet minimum hardware requirements. Disabling hardware option.
02.11.10 16:42:46 Increasing sound decompression buffer size to 1048576 bytes
02.11.10 16:42:47 WARNING: 1 clusters in structure_bsp levels\test\boxtest\boxtest_blue have no background sound or sound environment.
02.11.10 16:42:47 local player 0, weapon (0x0), deleted unexpectedly
02.11.10 16:43:21 EAX: 0x00000000
02.11.10 16:43:21 EBX: 0x00000040
02.11.10 16:43:21 ECX: 0xFFFFFFFF
02.11.10 16:43:21 EDX: 0x00000000
02.11.10 16:43:21 EDI: 0x0012E4E0
02.11.10 16:43:21 ESI: 0x0012EA0C
02.11.10 16:43:21 EBP: 0x0012E8B8
02.11.10 16:43:21 ESP: 0x0012E4C4
02.11.10 16:43:21 EIP: 0x00417E20, 8B 01 8B 96 ?????
02.11.10 16:43:21 0012FF94 ?????
02.11.10 16:43:21 004053C0 ?????
02.11.10 16:43:21 7FF89EB8 ?????
02.11.10 16:43:21 7FF514CE ?????
02.11.10 16:43:21 7FF5152C ?????
02.11.10 16:43:21 7FF528A2 ?????
02.11.10 16:43:21 00751B18 ?????
02.11.10 16:43:21 004F8200 ?????
02.11.10 16:43:21 EXCEPTION_ACCESS_VIOLATION
Apparently Dwood can't understand simple English, sending PM so I'm not cluttering this topic.Quote:
Originally Posted by Rambo
Edit: I don't know why you thought changing a bitmap would also change the sky tag, but that is not the case at all. The skies block has a maximum element count of 8, and in order to make the transition seamlessly you would need more than that. Looks like you won't be able to do this, oh well.
OK. Shadow helped me out. Now I need some help from FireScythe.
Fire, can you contact me on Xfire or AIM? I'll send you a PM with my contact information.
I don't know if you're aware of this Korn but Open Sauce doesn't let people modify globals that are in the maps.
1) And you tried this also in a stock engine setting?
2) And you tried this in a stock OS SDK build?
3) And you verified your spelling?
4) Define "doesn't let"
NVM for some reason its gone now, it must have been a problem with my scripts.
OpenSauce Vidoc Demo
Kornner Studios brings you Vidocs! The future of OpenSauce documentation
I've start work on the first official Vidoc this weekend (albeit, not to read as if it will also be done this weekend). While it won't give any one specific focus to a subject it'll give (or should at least) people the right mindsets when thinking OpenSauce.
A ViDoc? Wow, I'll be impressed when this is done. Is it mainly just basics of opensauce into the CE game, or is it also some advanced stuff that takes more practice in the codings of OpenSauce? (codings is used as an analogy)
I'm sure one or two will be made to give light some more advance topics. However, before I even go there I want to make sure people are in the right mind set about OpenSauce
After reviewing the draft material for the first Vidoc earlier I realized that I'd probably be better of breaking it up into a power-point and perhaps a short video recording to accompany it. While a Vidoc doesn't really have to be a video, it's the format everyone is use to. Should answer some of the basics for modders who take the time and review it.
What specific content are you going over so I may be able to give a suggestion?
No specific content but an overview of OpenSauce and what it is (and isn't). It seems like people never really caught on or felt the urge to automatically assume it was too advance for them, so I figured breaking it down and applying examples to their current modder state of mind would work the best. Without a Primer, going into specific topics would be fruitless. An internet thread can only deliver information in so few ways and lacks acceptable persistance methods (fuck HTML files) for offline viewing.
Ok. As an example, I think it would help a lot of the people who want to do things with open sauce if you did an example tag and showed how to add it into Open Sauce. Something simple... like a custom tag for text strings perhaps, just to show how to access them from OS?
Check out how he did the yelo_globals tags, he has sample code for those and it's fairly straightforward.
I'm going to need the assistance of some beta testers tomorrow/saturday for some things. You think you'll be able to assist Fire?
Choking, will you be able to test the animation importer?
Yea, I should be around. I'd be happy to test.
For the next update in OS, are you changing the Project_Yellow Tags at all? I'm designing my tag set up and want to know if you were going to make adding custom tags to the project_yellow stuff more version compliant, ie more places to add tag refs than the scenario and the global explicit references.
tag_collection. It solves any problems you just mentioned and both py tags support them.
The project_yellow tags are already as version compliant as the Halo1 engine allows them to be. No one should be changing the py tag structures except for me. If you're going to require new fields to support your code, make your own project's special tag. PY tags are for the operation of official OpenSauce releases.
Oh I know, i'm not trying to modify the original tags and all, and am going to make my own tags. I mean I just wanted to know if you were adding any other explicit references... (like the bsp and lightmap section of the tag)
Also, I don't know where you got the idea of me editing them....
If any new tag fields were to be added, they would be for a feature or something I was looking to stub or implement.
I was just saying in general: no one should ever change those tags or at least release anything which changes in them. That would be breaking versioning and they're not on the standards itty bitty titty committee for OpenSauce's core.
I'll be available from around 6:00 pm GMT tomorrow and over the weekend.
Good, was hoping you could test the new codebase, want to make sure I didn't find a way to break scripting support again ;p
Perhaps you could edit the tag (or include it in the ViDoc/Future SDK Documentation) so it's more obvious that people should be using tag_collection tags, because I see that area being a point of failure for those who just want to make maps, say... with Scythe's PostProcessing, or CV's animation permutations (not sure how you set it up man, just assuming you used that)Quote:
Originally Posted by Kornman00
I'll be sure to include a little diagram of what the setup for custom tags should be for devs and mappers in another explorial if I ever do make one.
Just like to let everyone know that the internal beta testing has been going great. We've already quashed some pretty annoying bugs and resolved some issues like the max animations limit override not fulling working for importing. Halo 1 looks to be right on schedule!
Has anyone managed to return a string in the new hs funcs? im trying to but so far it only returns gobbledy gook.
Yes, you have to return a char* that is cast as a void*. Which reminds me, when you return a char* does Halo delete the memory allocated there, or should it be a global pointer that the component handles completely?
Halo's scripting runtime won't manage that value you return to it. All up to you
Chances are the next update for this will be using VS2010 for its solution and project files. Just a heads up
Anyone Know if theres a tutorial on compiling this, i have the required things(boost C++ and Directx SDK) with Visual Studio 2010 and have had compiles errors every time
I have never been able to get it to compile in VS2010, use VS2008 instead and it should work fine.Quote:
Originally Posted by willfullcookie
thanks for the info. (woo, here i come large download!)
Edit~ after a overly large download of visual studio 2008 i installed it and reinstalled the others(just in case) however the compile still failed, i suppose i should mention that im on a 64bit computer..
someone can tell me how to install this!
"I have little knowledge of 3D, and if I can serve, just let me know.
Also if anyone can teach me a little of what they know, i would be happy to learn "
PD: I speak Spanish
PD2: I do what can to understand what they say.
u.u
So I lied when I said the next release's source would be for VS2010. While I want to move to the latest and greatest VS, I figure that not everyone else may feel the same or their only option for 2010 may be the Express versions (but not for 2008). So yeah, the next codebase release will still be VS2008.
I'm also working on making the .NET tools that accompany the OpenSauce SDK compliant with x64 targets. Whether or not the tools will see any speed improvements is questionable (I'm not spending any time to gather profiling metrics). Obviously, I can't make the Yelo component of OpenSauce x64 compliant as the Halo engine and its tools are all x86 based. Also, I think Express versions of VS don't have x64 tools so you'll still be stuck with compiling for x86 targets.
There's been some...delays you could say. Moving has fucked with development but I can still work on parts of OpenSauce again and hey, I can even run HaloCE again :party:.
I was hoping to put out a new update about OS in the spirit of Bungie Day but I've been up since yesterday and blah blah blah, life, etc etc, tired as fuck, etc etc, school, etc etc. So instead the official update will have to wait some odd amount of days.
Just to give you an idea of what's going on though, I've started integrating (part of the reason I've been up all night, the other being 7 seasons of TPB) what I hope will be the final reversion of the Postprocessing system. FS sent me his codebase the other day and I've been reviewing it all, making sure it adheres to to a few standards (OS and Halo standards). We've also got some stuff in the process of being researched and developed that I think will really just add some fucking major pizazz to maps of anyone who uses who uses what we're baking. However, I don't want to go into any explicit details until we're positive that we know we can execute it right and without consuming too many resources. So I'll just leave you with that little tease for now!
Plenty of other surprises to watch out for too; HaloCE isn't the only boat being sailed these days. So yeah, I think I'll be nice and let Bungie have the spotlight for today while I try to catchup on some missed sleep. That and I don't want to jinx myself for a third time...
There's no spotlight for you unless you made the new networking work. :P
Anyone who is working on OS related code modifications needs to contact me ASAP if they wish to have their changes considered for inclusion in the official OS2.5 release. Anyone who can't have their changes done and tested by August need not apply.
I just added light-map switching (works) and exposed the isKeyDown function to halo script. want to include that?
I've had "structure_bsp_lightmap_reset" and "structure_bsp_lightmap_set_change" implemented for a while now, but haven't had a chance to test that they actually work. If someone can provide the sample data (test lightmaps, yelo tags, etc) using tutorial then I can make sure it is changing the lightmap/sky based on what the tag data specifies. Note that the "skies" block must match what the scenario's "skies" block exactly (every reference, in the same order) in order for sky switching to work with your lightmap set changes.
I had shadow test with tutorial and lightmap-set switching functions I wrote work (lightmap and sky changes)Quote:
Originally Posted by Dwood
plus many other things.
wouldn't be right of me to not tease about magical mystery features that are in and working ;p.
Those are the wrong things to tease about! :PQuote:
Originally Posted by Kornman00
Any way to check if someone is in a vehicle? First Seat and not being in a vehicle share TStructGetPtrImpl(int16, VehicleSeatIndex, 0x2A) being '0'.
Also, how can I check if someone is still in a server? I don't think I found an implementation for this in OS but I thought this was the right thread for asking :v:
You'd have to check if the player's slave unit has a null parent-object-index or not.
By iterating over the player_data you can interface with all active players. The data iterator skips any datum which is invalid (read: not allocated for use).
I thought you were done with Halo?
Using your OS as a info sauce. Trying to incorporate some of my math ideas into a bot (...which I will not release). Halo is a good sex slave for doing this kind of stuff.
Also, it would require a bit of work but implementing a signature system to get the offsets right on every version would help a lot don't you think? Halo Sausage would work on every version then (afaik). I could help you with that.
The codebase isn't setup to use dynamic addresses and I really don't see anymore updates past 1.09, at least not anytime soon. Not only that but some function hooks are done at the very end of the function they're hooking. This is a problem because some of the patches done to the client\dedi have caused the padding bytes between functions to fall under 5 unused bytes (and you need at least 5 to perform relative branches). This would still leave version specific junk in the code. Then you'd have to test for each build of the game to make sure this theoretical signature system doesn't give false positives to function and data memory addresses.
I'm not here to support egg heads who are still running around on 1.00. They're all pirates to me and I don't support people who feel they can't shell out less than 10$ or whatever to play a 7 year old game that they still enjoy.
If someone wants to develop and prototype the implementation into OS on their own then fine. But I'm not taking part in it.
@Pat
Even though Kornman00 gave me crap about it too I still worked on it lol. I tried modifying the ENGINE_PTR/FUNC_PTR macros with a sig scan routine but of course it doesn't work because they are macros and ran through the pre processor first. It would've made everything really really easy that way. You would have to scrap those macros and edit each function pointer to run through the scan routine, which I didn't even want to get started on. I have a signature generator and scanner that won't give false positives he was mentioning. Of course the longer the signature the more unique it is. The other butt hurt part is going to be data pointers, to scan for them you have to reference from code, but to save time you can write a routine to search for them and generate a signature too. I'll contact you later
Does Engine::Objects::GetLocation() return screen coordinates of the object position? And GetOrigin() returns the object position? And GetCameraPosition() returns the position of the camera that is attached to the specified object? Merr?
I made a final decision to use OS to build Forge CE. I doubted myself before and even though I am a hobbyist programmer, it wasn't until recent that I realized how omnipotent OS is. Thanks for this.
GetLocation is actually mis-documented. It copies the object's scenario location. A scenario location houses the bsp leaf and cluster index that the object is currently located by (this will be fixed in the next release, don't worry).
GetOrigin gets the position of object in the game world. If its a child object, it uses the parent object to calculate its world position.
GetCameraPosition is for unit based objects only and it calculates the view position based on the unit's 'head' if it has one. If not, it will estimate the sight position based on the object's origin.
Awesome thanks. Also what would happen if I passed an object datum_index to one of these functions that is actually to an invalid / non-existent object? Will it pass a null pointer or will it just crash? I guess I could test for myself.
Oh yea, I wanted to shorten my code by using the - operator to subtract two real_point3d variables that equal a real_vector3d, because I use Magnitude() on the result -- but it says the - operator is ambiguous and won't let me. Is there a way I can do this without initializing each member individually? For now I'm using Set(), but vect = point - point would be super!
Because of OS, my development time is tenfold!!
In OS2 RC, if the engine function code doesn't have a null handle check then it will crash. If you're passing a handle which is to a datum that is no longer active then it will more than likely crash too. However, as long as you're using the game state's memory for data handles you should be fine. If you're not keeping your handles up to date then it's on you for having crashes from inactive datum accesses.
real_point has operator overrides for casting to real_vector and D3DXVECTOR types. So just cast the real_point to a vector then you can use the vector's manipulators.
I haven't yet tried type casting, I will get to that later. Right now GetOrigin is crashing Halo for some unknown reason. I used YELO_DEBUG_FORMAT to print out the object handle and object address before calling it. All the other printed data is fine and working great. I don't see anything wrong, but maybe you might? Thanks
http://www.pastebin.com/Kjg2hB6H
Debug output of my last test:
Edit: Fixed a few things, updated but still crashing.
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.