A Community discussion forum for Halo Custom Edition, Halo 2 Vista, Portal and Halo Machinima

Home  Search Register  Login Member ListRecent Posts
  
 
»Forums Index »Halo Custom Edition (Bungie/Gearbox) »Halo CE General Discussion »[WIP] Invader

Author Topic: [WIP] Invader (32 messages, Page 1 of 1)
Moderators: Dennis

Kavawuvi
Joined: May 24, 2018

Brrrrrrring Ha!


Posted: May 30, 2019 02:07 AM    Msg. 1 of 32       
Invader is a work-in-progress, cross-platform, open source project that builds cache files. I've been working on this for a while and I figured I'd share my progress.

How close to completion is Invader?
Invader is still fairly incomplete and won't work with many maps, especially maps with scripts. I do not recommend using it outside of testing for now, but it is working with more and more maps as progress is being made. This is the reason why I don't have binary builds of it available just yet.

Why make this when we have Tool?
The biggest drawbacks of tool.exe are that it's unsupported and closed source. We need it to do more than what it did when it came out, but the best we can do is hacking and patching the executable. This is very limiting when it comes to wanting to do more than what is allowed. Considering the MEK is replacing parts of the Halo Editing Kit, it makes sense to replace this enigmatic piece of software.

In layman's terms, tool.exe is a piece of software filled with black voodoo magic, and being software from the 90's, it sometimes requires various demonic rituals in order to function as intended. The MEK is the bane of evil and Invader is the light.

What are some features?
One useful feature of Invader is that it can build cache files in any tag order you want. This means that you can export the tag list of a multiplayer map, rip the map, modify the rip, and then rebuild the map using the same tag order as before. You can then run the map through Refinery's CRC spoofer, allowing you to use that map in place of the original map online. This is great for if you want to add or change content on the stock multiplayer maps while still allowing these maps to be played online.

Invader is also very fast. Here's a benchmark I ran last October.


Will Invader work on a Mac?
While I don't have any means of building Invader for macOS, it will most likely compile just fine considering it compiles perfectly fine for Linux and Windows. If so, this along with the MEK can be a useful step for Mac users being able to make maps without having to resort to Wine or having an installation of Windows. It's sure been long enough, after all.

How do I get Invader?
The recommended way to get Invader is to compile it from source which you can get here: https://github.com/Kavawuvi/Invader

Alternatively, if you're on a 64-bit version of Windows, you can download the latest nightly build. These builds are built off of code from the GitHub repository at whatever state it is at the time, but they may be slightly outdated if code has been committed recently.

Edited by Kavawuvi on Aug 18, 2019 at 01:59 AM


BioGoji1989
Joined: Dec 24, 2017

Professional Idiot


Posted: May 30, 2019 11:53 AM    Msg. 2 of 32       
Quote: --- Original message by: Kavawuvi

In layman's terms, tool.exe is a piece of software filled with black voodoo magic, and being software from the 90's, it sometimes requires various demonic rituals in order to function as intended.


Hey! You leave our demonic rituals alone! We like sacrificing Minecraft and Destiny players to the cmd.exe god!


lolslayer
Joined: Mar 21, 2015

https://www.youtube.com/watch?v=uMHbAKvPJkU


Posted: May 31, 2019 03:54 PM    Msg. 3 of 32       
Sounds nice, are there already limitations of tool that Invader breaks?


Kavawuvi
Joined: May 24, 2018

Brrrrrrring Ha!


Posted: May 31, 2019 04:18 PM    Msg. 4 of 32       
Quote: --- Original message by: lolslayer
Sounds nice, are there already limitations of tool that Invader breaks?

Yes. Here is a short list:

  • Stock tool does not allow maps to be >384 MiB. Invader does not have this limitation and will happily output maps up to 4 GiB, and Halo will read the maps fine.

  • Stock tool does not allow some reflexives/tag blocks to exceed a certain limit such as netgame equipment. Invader does not have restrictions for most of these, and Halo will read the maps fine.

  • Stock tool only allows indexed, external tags in multiplayer maps despite the game not having this restriction. This results in broken bitmaps and sounds as well as English strings when playing an English UI/SP map on a non-English installation. Invader will use indexed tags for all types of maps, allowing the map to work on all languages of the game.

  • Invader does a small amount of deduplication to tag data, allowing you to put a little bit more tag data in the 23 MiB tag space. I'm planning on expanding on this feature later, but this may mean that you can build some maps that cannot possibly be built in tool.exe without removing tags.

  • Invader does not fail to open bitmaps.map, sounds.map, or loc.map if you have Halo open.


Invader also has a nicer, easier-to-read text output than tool.

tool.exe:
Couldn't read map file './toolbeta.map'
the meter definition ui\hud\cyborg shield does not specify a stencil bitmap group.
the meter definition ui\hud\cyborg body does not specify a stencil bitmap group.
WARNING: 1 clusters in structure_bsp levels\a10\a10_space have no background sound or sound environment.
WARNING: command list DUP107~look_at_halo could be ambiguously attached to BSPs #1 and #8
WARNING: command list DUP119~look_at_halo could be ambiguously attached to BSPs #1 and #8
culling uncompressed model vertices...done
culling uncompressed structure bsp vertices...done
culling uncompressed model animation data...done
building predicted resources for structures...done
structure bsp 'levels\a10\a10a' is 8.25M
structure bsp 'levels\a10\a10b' is 10.94M
structure bsp 'levels\a10\a10c' is 8.04M
structure bsp 'levels\a10\a10d' is 7.27M
structure bsp 'levels\a10\a10e' is 10.35M
structure bsp 'levels\a10\a10f' is 11.39M
structure bsp 'levels\a10\a10g' is 11.49M
structure bsp 'levels\a10\a10_space' is 1.90M
structure bsp 'levels\a10\x10hangar' is 3.62M
tag headers and names are 0.30M
streaming model vertex and index buffers...done
streaming tags.....................................done
writing vertex and index buffers...done 8.70M
writing tags...done (3724 tags for 9.79M)
total tag size is 21.28M (1.72M free)
compressing 190.96M...done
successfully built cache file.
Cache pack file bitmaps hits: 606 for 33.23M
Cache pack file bitmaps adds/misses: 438 for 46.79M
Cache pack file sounds hits: 428 for 7.36M
Cache pack file sounds adds/misses: 2514 for 53.64M
Cache pack file loc hits: 52 for 0.11M
Cache pack file loc adds/misses: 13 for 0.01M

Invader:
Scenario name:     a10
Tags: 3724 / 65535 (82.33 MiB)
BSPs: 9 (73.17 MiB)
levels\a10\a10a (8.24 MiB)
levels\a10\a10b (10.93 MiB)
levels\a10\a10c (8.03 MiB)
levels\a10\a10d (7.26 MiB)
levels\a10\a10e (10.34 MiB)
levels\a10\a10f (11.37 MiB)
levels\a10\a10g (11.47 MiB)*
levels\a10\a10_space (1.90 MiB)
levels\a10\x10hangar (3.61 MiB)
Tag space: 21.06 / 23.00 MiB (91.57 %)
Model data: 8.43 MiB
Bitmaps/sounds: 98.85 MiB
Indexed tags: 572
File size: 189.89 MiB
Time: 1015.425 ms


You can also make it not output anything at all, too. Outputting text to console takes a lot more time than it sounds.

That's all I can think of off the top of my head. I've got more plans for it if/when I finish it.

Edited by Kavawuvi on May 31, 2019 at 04:18 PM


PRPatxi
Joined: Oct 30, 2010

Dennis, free me from this suffering


Posted: Jun 1, 2019 02:59 PM    Msg. 5 of 32       
It's like 8 years since I last saw someone using switch statements in their code.


Kavawuvi
Joined: May 24, 2018

Brrrrrrring Ha!


Posted: Jun 4, 2019 01:38 AM    Msg. 6 of 32       
I got AI encounters to not T-pose and actually work. There are still some things to fix (model permutations and some AI behavior issues) and not all AI encounters are fixed, but the campaign is now playable.


Quote: --- Original message by: PRPatxi
It's like 8 years since I last saw someone using switch statements in their code.

I use what I feel makes sense at the time for what I'm writing. Switch statements are pretty useful for control flow.

Edited by Kavawuvi on Jun 4, 2019 at 05:16 AM


lolslayer
Joined: Mar 21, 2015

https://www.youtube.com/watch?v=uMHbAKvPJkU


Posted: Jun 5, 2019 04:57 AM    Msg. 7 of 32       
Great stuff, thanks for making such great tools for Halo <3


OrangeJuice
Joined: Jan 29, 2009

new content isn't a mod. hhtmods are mods.


Posted: Jun 5, 2019 04:37 PM    Msg. 8 of 32       
It was fun seeing the earlier screenshots of it and the interesting ways it messes up halo, now this looks even nicer


Kavawuvi
Joined: May 24, 2018

Brrrrrrring Ha!


Posted: Jun 6, 2019 05:47 PM    Msg. 9 of 32       
Many of the AI encounters do not work properly still. Navigating this BSP tree thing has been quite difficult as it's not that well documented.

However, many multiplayer maps work quite well. It's not perfect, but it's getting pretty close to that and I'm really excited for when I complete this.

I may start releasing beta builds of Invader soon so people who don't want to compile Invader from source can test it.

That said, I don't want my topic locked (No double post rule FTW! /s), so when I start releasing beta builds, I'll only be able to post new builds on this topic whenever someone replies. Otherwise, you'll be able to find releases on the GitHub repository if they come out. I hope that's okay.

Quote: --- Original message by: OrangeJuice
It was fun seeing the earlier screenshots of it and the interesting ways it messes up halo, now this looks even nicer

Making a tool.exe replacement has been a long journey with many ups and downs. One of the main obstacles to doing this is the fact that there is so much stuff in a Halo map that isn't even exposed by Guerilla and is only set/generated on map build. Copying the tag data is most of the work, sure, but it's the little things that keep things from looking messed up.

I will also say this too: Relying on closed source software for creating maps and assets is not good for the long term health of the modding community. The Halo Editing Kit is, unfortunately, just that. There are also numerous other projects out there that are closed source and will most likely never be open source. Such software should eventually be replaced with open source software.

I hope that one day the entire Halo Editing Kit and every other closed source tool that people have released will be replaced. The MEK is such a great effort for this, and I want Invader to be another useful alternative for modders to use, as there is so much we can do with this.


BKTiel
Joined: Mar 18, 2014

strong independent bird needs no cage


Posted: Jun 7, 2019 01:41 AM    Msg. 10 of 32       
you are a good man


DeadHamster
Joined: Jun 8, 2014

https://discord.gg/Neu4EJM


Posted: Jun 7, 2019 07:19 AM    Msg. 11 of 32       
Do you plan on replacing tool's full function set or just the section of map building? Because there's a lot of changes that could be made in relation to raw resource compiling which is where tool really falls short. Allowing multiple formats to be compiled to sounds/bitmaps and changing how shaders are for selected for compiling models/BSP would be the first two.

Tool requires specific source formats of course, and for shaders Tool goes through all the tags inside the TAGS folder and finds the first shader with a matching name and assigns it. However if a user has too many tags/files to check, this process fails and tool is unable to compile the model. I actually keep a separate directory just to compile models and BSPs.


Kavawuvi
Joined: May 24, 2018

Brrrrrrring Ha!


Posted: Jun 7, 2019 10:23 PM    Msg. 12 of 32       
I haven't done benchmarks in a long time. This time, I decided to take Invader and tool.exe and make them build every single multiplayer map in the game. Here are the results (click to expand):



Takeaways:

  • Invader is faster than tool.exe (around 411% faster on Linux, around 213% faster on Windows)

  • Invader is around 15-17% faster when compiled for 64-bit depending on OS

  • Invader is around 82% faster when compiled for Linux but still quite fast on Windows

If you want to test the exact builds I used, you can download them here. I don't recommend using these for anything serious as it's pretty far from completion. Note that when Invader is released, only 64-bit builds will be released. Therefore, if you want Invader to run on a 32-bit operating system, you will need compile it yourself.

Quote: --- Original message by: DeadHamster
Do you plan on replacing tool's full function set or just the section of map building? Because there's a lot of changes that could be made in relation to raw resource compiling which is where tool really falls short. Allowing multiple formats to be compiled to sounds/bitmaps and changing how shaders are for selected for compiling models/BSP would be the first two.

Tool requires specific source formats of course, and for shaders Tool goes through all the tags inside the TAGS folder and finds the first shader with a matching name and assigns it. However if a user has too many tags/files to check, this process fails and tool is unable to compile the model. I actually keep a separate directory just to compile models and BSPs.

I do agree that there are a lot of things that can be done for replacing tool.exe. Invader currently just does map building, though I do plan on having other functionality besides map building that could be useful. tool.exe is a program with a lot of uses and features, and replicating everything will not be one easy task.

In fact, the program for building map files is invader-build.exe rather than invader.exe as I'm also working on other tools as part of Invader such as invader-indexer (tag indexing) and invader-scenario (scenario tag editing for use with Blender). Invader isn't just one thing here.
Edited by Kavawuvi on Jun 7, 2019 at 10:34 PM


Kavawuvi
Joined: May 24, 2018

Brrrrrrring Ha!


Posted: Jun 8, 2019 04:46 PM    Msg. 13 of 32       
So here's an update:

I fixed lightning tags (I think?) so those should work fine now.

I'm still trying to figure out navigating the collision BSP tree so I can place AI encounters accurately. For some reason Invader isn't correctly setting some encounters to the correct BSP on certain maps like d40 and b30, so I'm going to be spending a great deal of time fixing those. I've been spending several days on this, too, but I'm coming fairly close. Just not close enough.

If I fix these issues and I fix other AI behavior issues, then campaign maps should work perfectly or close to perfection. So this means that I have come very close to finishing Invader.

I'm also planning on adding deduping to more types of tag data. I did it to animations and tag paths for a while and it reduced tag space usage by a around 1 MiB in some maps. This may not sound like a lot if you don't make maps, but a problem with the stock engine is that you're only allowed 23 MiB of tag space, and this space is shared with the currently loaded BSP. Saving a MiB means saving an extra 4% of that tag space.

As you can imagine, being limited to 23 MiB of tag space can make it very easy to go over the tag space limit on some maps. Adding a complex animation tag, using a complex BSP, or even simply adding enough spawns for something could very well push the map over the edge in some cases. But having an extra 4% of space could be the difference between the map failing to build and the map building successfully. The best part? Deduping doesn't require Open Sauce.

If anyone wants to test this, here: https://drive.google.com/open?id=1p1X9x6MyJGbYyd0qavef-cFWB2S78KVG.

Quote: --- Original message by: BioGoji1989
Here's a free bump so that you can post another update later!

Keep up the good work! I hope to see this tool replacement in action in a final build someday.

Ooh, thanks! That's very much appreciated (Also, thank you DeadHamster. I saw your post but it got deleted).

Edited by Kavawuvi on Jun 8, 2019 at 04:49 PM


SBB_Michelle
Joined: Nov 4, 2015

This site brings me pain.


Posted: Jun 9, 2019 05:43 AM    Msg. 14 of 32       
Nice space gains. I hope you can figure out the ai BSP attachment thing without too much more hassle.

Gotta love tool being compiled as a debug build making it slow.

I really think having an opensource map compiler will benefit us all at some point.


Kavawuvi
Joined: May 24, 2018

Brrrrrrring Ha!


Posted: Jun 11, 2019 02:38 AM    Msg. 15 of 32       
Here's another update.

- AI encounters now default to 0xFFFF if they don't have any spawns. This should remove some of the "0 BSPs" warnings that you may see, notably The Silent Cartographer (b30.map).

- I figured out how to calculate a certain hidden value in the biped tag (that is, the head node index). Before this, I assumed it was always 12, but some bipeds have it set to something different. This value affects aim assist as well as certain cutscenes. This notably affects the part where Captain Keyes says "Let's give our old friends a warm welcome." in The Pillar of Autumn (a10.map), as setting it to 12 instead of the correct value results in the camera zooming in on his ear instead of his face.



Due to personal reasons, I'm going to be posting most updates on Open Carnage so if you want this build, I recommend going there. Check there if you want any further news on Invader. I'll still stick around here to answer questions if anyone has any, though, and I'll also post here when I finish version 1.0 of Invader.

Thank you for your interest!

Quote: --- Original message by: SBB_Michelle
Nice space gains. I hope you can figure out the ai BSP attachment thing without too much more hassle.

It's mainly just a matter of trying to calculate whether or not something is inside of a BSP. I have it down to something that's semi-accurate but not 100% accurate.

Quote: --- Original message by: SBB_Michelle
Gotta love tool being compiled as a debug build making it slow.

Yeah, that hurts a bit. Invader as a debug build is a bit slower than the release build, but it's still considerably faster than tool.exe. I suspect this is due to me using a newer compiler, a newer CPU architecture (x86_64 vs. x86), and probably just more efficient code altogether. I also do fewer checks than tool.exe, and I do nearly everything in RAM, so that may contribute to a non-trivial portion of the speed improvements.

Quote: --- Original message by: SBB_Michelle
I really think having an opensource map compiler will benefit us all at some point.

Me too. I think it's pretty impressive what people have done with modifying the existing tool.exe, but I imagine that having an open source map compiler will make things a lot easier.


sparky
Joined: Jun 27, 2009

Jesus is a friend to the vindictive sociopath


Posted: Aug 11, 2019 09:51 AM    Msg. 16 of 32       
Quote: --- Original message by: Kavawuvi

probably just more efficient code altogether. I also do fewer checks than tool.exe

having an open source map compiler will make things a lot easier


I'm guessing you looked at the assembly many times by now and have been using the proprietary IDA, yes?

Why do you like open source so much? If no one else is going to contribute to a project, why do open source rather than simply share the source code as text files when it's done?

Also, what was involved in determining some of these undocumented values like at the end of bipd?

Anyway, it's nice that you are still an active software developer in this community.


Kavawuvi
Joined: May 24, 2018

Brrrrrrring Ha!


Posted: Aug 11, 2019 05:42 PM    Msg. 17 of 32       
Quote: --- Original message by: sparky

I'm guessing you looked at the assembly many times by now and have been using the proprietary IDA, yes?

I have not used IDA for this project. People have offered to give me .IDB files for Halo Custom Edition and a pirated copy of IDA Pro to better help me find things in the Halo executable in the past, but I haven't really found any need for either of them.

Quote: --- Original message by: sparky

Why do you like open source so much? If no one else is going to contribute to a project, why do open source rather than simply share the source code as text files when it's done?

Invader spans over 43 thousand lines of code with almost 200 source files. For a small project being done by only one person, that's a lot of code, and version control makes it easier to manage when I need to track changes or go back in time for whatever reason.

Besides adding a LICENSE file, there is no additional effort required on my part to make my project open source. This is because the only difference between open source and closed source is that, rather than using a private repository for version control, I push commits to a public one. For me, this is a simple flip of the switch.

People can choose to contribute to the project if they want. If they don't, I suppose it wouldn't be any different from me choosing to not open source my project. If they do, then the Invader project benefits from their contribution.

Lastly, I have nothing to gain by holding back information prior to completing the project. In fact, by making the Invader toolkit open source, I have nothing to lose and everything to gain.

Quote: --- Original message by: sparky

Also, what was involved in determining some of these undocumented values like at the end of bipd?

Change values in Guerilla, run tool build-cache-file, check value in hex editor, and write down the result. After a few iterations, a pattern becomes visible, and I test it over the next few iterations to make sure it's correct.

Quote: --- Original message by: sparky

Anyway, it's nice that you are still an active software developer in this community.

Thanks!

Edited by Kavawuvi on Aug 11, 2019 at 05:42 PM


sparky
Joined: Jun 27, 2009

Jesus is a friend to the vindictive sociopath


Posted: Aug 12, 2019 12:04 AM    Msg. 18 of 32       
Quote: --- Original message by: Kavawuvi
Quote: --- Original message by: sparky

I'm guessing you looked at the assembly many times by now and have been using the proprietary IDA, yes?

I have not used IDA for this project. People have offered to give me .IDB files for Halo Custom Edition and a pirated copy of IDA Pro to better help me find things in the Halo executable in the past, but I haven't really found any need for either of them.


There are advantages to looking at the assembly, including seeing what registers and addresses and pointer types are used to determine data type of a variable, and seeing what resources are used and what a function actually does. So it's definitely an option with clout.

Quote: --- Original message by: Kavawuvi
Quote: --- Original message by: sparky

Also, what was involved in determining some of these undocumented values like at the end of bipd?

Change values in Guerilla, run tool build-cache-file, check value in hex editor, and write down the result. After a few iterations, a pattern becomes visible, and I test it over the next few iterations to make sure it's correct.

This would have been my approach also. But now since you made your work (publicly) visible to me, I can see what you determined and determine myself if your conclusions are accurate. Peer and third-party review is one advantage to using open source, but the question remains as to whether or not I would actually commit changes. I would be more inclined to send you my comments than to directly commit changes. (Also, these undocumented values are relevant to MosesofEgypt's Mozzerilla project, so he may be interested in reviewing your conclusions. I mention this specifically because he considered my initial guesswork at those undocumented biped fields, where I simply changed them using a memory editor to see what happened in the game.) So at least your work is appreciated by other software developers who are interested in that kind of information. But like if I'm a C programmer and I do reverse engineering work, I would be more inclined to comment than commit or fork and push into a C++ project. The question here is one of how useful my existing work is and my future work would be to another project like this written in a different programming language. I mean, you already have my extracthalotagdefs pastebin and my other files (tags, not maps yet) far more recent than my old Eschaton plugins...

...too wordy, I know. In sum, I suppose open sourcing as a general available opportunity for others to possibly contribute, without any real implied initiative or main purpose of their contributing -- compared to collaborative map authoring in the game over a network -- seems like just giving yourself more extraneous work to manage push requests. It doesn't seem like much extra work to do that, but it's the attention that takes time and distracts from development focus. And of course, it's easier to take an idea with information and apply it to your own project according to your own design principle rather than to work with someone else's code as it's written into your project files, especially if they don't know what the design principles are. Compare to two map authors working on a map at the same time in an uncoordinated way, where one is shifting around vertices of the BSP while the other is trying to texture and UVW map that BSP at the same time.
Edited by sparky on Aug 12, 2019 at 12:06 AM


Kavawuvi
Joined: May 24, 2018

Brrrrrrring Ha!


Posted: Aug 13, 2019 03:05 PM    Msg. 19 of 32       
Quote: --- Original message by: sparky

There are advantages to looking at the assembly, including seeing what registers and addresses and pointer types are used to determine data type of a variable, and seeing what resources are used and what a function actually does. So it's definitely an option with clout.

I don't doubt there are advantages, many of which nearly paramount to a project like this. However, I think my methodology is adequate enough for this task.

Quote: --- Original message by: sparky

This would have been my approach also. But now since you made your work (publicly) visible to me, I can see what you determined and determine myself if your conclusions are accurate.

Given that it matches up perfectly with all of the values in the stock tags, I am quite confident that my findings are accurate.

Quote: --- Original message by: sparky

Peer and third-party review is one advantage to using open source, but the question remains as to whether or not I would actually commit changes. I would be more inclined to send you my comments than to directly commit changes. (Also, these undocumented values are relevant to MosesofEgypt's Mozzerilla project, so he may be interested in reviewing your conclusions. I mention this specifically because he considered my initial guesswork at those undocumented biped fields, where I simply changed them using a memory editor to see what happened in the game.) So at least your work is appreciated by other software developers who are interested in that kind of information. But like if I'm a C programmer and I do reverse engineering work, I would be more inclined to comment than commit or fork and push into a C++ project. The question here is one of how useful my existing work is and my future work would be to another project like this written in a different programming language.

From my understanding of you, you most likely find your own work to be superior to my work and that your projects will be better than anything I do. Despite you commenting on this topic, I'm not convinced that you would have any interest in Invader even if it was written purely in C.

Quote: --- Original message by: sparky

I mean, you already have my extracthalotagdefs pastebin and my other files (tags, not maps yet) far more recent than my old Eschaton plugins...

I don't think I have it. I generally don't use Eschaton except for extracting tags to disk so I can compare them using hex editors.

Quote: --- Original message by: sparky

...too wordy, I know. In sum, I suppose open sourcing as a general available opportunity for others to possibly contribute, without any real implied initiative or main purpose of their contributing -- compared to collaborative map authoring in the game over a network -- seems like just giving yourself more extraneous work to manage push requests.

If people are working on stuff at the same time as I am, it can be, overall, more efficient. Sure, if someone makes a pull request, I'll have to commit time to reviewing their code, but that doesn't take nearly as long as writing the code. So, it's less work for me to do in the end.

Also, if people don't know what to do, there is a list of issues.

Quote: --- Original message by: sparky

It doesn't seem like much extra work to do that, but it's the attention that takes time and distracts from development focus. And of course, it's easier to take an idea with information and apply it to your own project according to your own design principle rather than to work with someone else's code as it's written into your project files, especially if they don't know what the design principles are.

My principles are likely self-explanatory. If not, they're probably simple enough to explain.

Quote: --- Original message by: sparky

Compare to two map authors working on a map at the same time in an uncoordinated way, where one is shifting around vertices of the BSP while the other is trying to texture and UVW map that BSP at the same time.

I don't know if I would compare it to that. The design of a BSP is subjective. Invader's design is mostly objective with the objective being to build cache files. Much of this stuff can only be done correctly in a limited number of ways if not one way.

Edited by Kavawuvi on Aug 13, 2019 at 03:08 PM


sparky
Joined: Jun 27, 2009

Jesus is a friend to the vindictive sociopath


Posted: Aug 14, 2019 07:47 AM    Msg. 20 of 32       
Quote: --- Original message by: Kavawuvi
Quote: --- Original message by: sparky
I mean, you already have my extracthalotagdefs pastebin and my other files (tags, not maps yet) far more recent than my old Eschaton plugins...

I don't think I have it. I generally don't use Eschaton except for extracting tags to disk so I can compare them using hex editors.


No offense to Altimit01, but I feel wrong every time I consider using Eschaton, and I feel stupid every time I do use Eschaton. It's like, "Why am I doing this?" because I would sooner be spending the time working on my own application. Using Eschaton should not remain necessary for Mac and Windows users given that we can learn from what Altimit01 did and try to do things better. Anyway, here are links to my former works of interest since my Eschaton plugins:

SAPP Lua Template
HTTPD Apache APR file type handler extension (old version from past experiments)
Halo Tag File Definitions
extracthalotagdefs in Objective-C to produce Halo Tag File Definitions
diffs by Smx for Windows, changing #import to #include and using binary mode with fopen
retribution.h
halo_definitions.h
halo_bitfields.h
halo_enums.h
guerilla.txt before I learned that unix has a "strings" command
crc32 calculation from some web site
crc32 calculation from some web site using a lookup table, put into C#
flam.h for peer comment
flam_bitmasks.h
halo_constants.h
flam_enums.h

Again, old stuff. And you have a whole slew of other people's work and your own experience.

As I showed in a more recent video, I finished putting the Halo tag definitions into C structs. If you are interested, you can read it off the video. I don't share or leave open source what I'm still working on.

Maybe some of that is useful to your project.

EDIT:

Not that you would appreciate any of it...

Edited by sparky on Aug 16, 2019 at 12:14 AM


Kavawuvi
Joined: May 24, 2018

Brrrrrrring Ha!


Posted: Aug 17, 2019 02:35 AM    Msg. 21 of 32       
Quote: --- Original message by: sparky

As I showed in a more recent video, I finished putting the Halo tag definitions into C structs. If you are interested, you can read it off the video. I don't share or leave open source what I'm still working on.

Perhaps the problem this community has is that people seem to be obsessed with keeping details of this game secret. That's why they do things like map protection as well as creating closed source tools that many people have no choice but to rely on due to the (also closed source) HEK tools being inadequate. That's ultimately why I like open source so much.

Quote: --- Original message by: sparky

Not that you would appreciate any of it...
https://i.imgur.com/lfW03zy.png
Edited by sparky on Aug 16, 2019 at 12:14 AM

I apologize for my harsh words.

Given your actions from the past and many of your recent actions, I now realize what kind of a person you are, and I think I've been looking at you the wrong way.

What actions? You talk down everyone like you're the best, but when given any criticism, you completely ignore it and try to shut down the opposition as if their opinion doesn't matter. You also try your best to be in the center of attention as if everything you do is sacred and what everyone else does is wrong, as if you're the only person worth any sort of validation. In the end, you spend so much time pushing people away that there is nobody left to truly appreciate you.

You're very bright and very intelligent, and obviously you're very dedicated (hence my "herpes" joke). I think it's truly unfair, though, that, although you were gifted such talents, you're also so very sour. Is it because of this wicked community that you've spent so much time in? Or is it something else entirely? Either way, I know you can do so much better if you tried.


MosesofEgypt
Joined: Apr 3, 2013


Posted: Aug 17, 2019 04:04 AM    Msg. 22 of 32       
What that guy said.


Dennis

Joined: Jan 27, 2005

"We are made of starstuff. ― Carl Sagan


Posted: Aug 18, 2019 12:02 AM    Msg. 23 of 32       
Quote: --- Original message by: MosesofEgypt
What that guy said.
The term you are looking for is narcissism.


MosesofEgypt
Joined: Apr 3, 2013


Posted: Aug 18, 2019 12:18 AM    Msg. 24 of 32       
Quote: --- Original message by: Dennis
The term you are looking for is narcissism.

Also what this guy said.


Kavawuvi
Joined: May 24, 2018

Brrrrrrring Ha!


Posted: Aug 18, 2019 12:19 AM    Msg. 25 of 32       
Anyway, if anyone is interested in Windows Invader builds, things are uploaded here: https://invader.opencarnage.net/builds/nightly/download-latest.html

All Windows builds I post here will be 64-bit only (unless I goof up and compile for 32-bit by mistake). If you're on a 32-bit version of Windows, now is the time to upgrade (actually... that time was over 10 years ago, but better late than never).

If you need to run Invader on a different OS/architecture (e.g. macOS, 32-bit x86, or ARM), you will have to compile it yourself from source. To be honest, I recommend doing this regardless for potentially slightly better performance, but I doubt most of you want to take the time to do that.

Have a wonderful day! And if anyone has any questions, feel free to ask here.

Edited by Kavawuvi on Aug 18, 2019 at 12:21 AM


Halonimator
Joined: Dec 15, 2014

https://imgur.com/a/pVhmSgX


Posted: Aug 18, 2019 01:50 PM    Msg. 26 of 32       
How Many Times Do I Have to Teach To Sparky The Lesson Of Not Commming Back? Does he enjoy my mayhem!?!


Kinnet
Joined: Dec 27, 2013

FeelsGoodMan


Posted: Aug 18, 2019 02:46 PM    Msg. 27 of 32       
Quote: --- Original message by: Halonimator
How Many Times Do I Have to Teach To Sparky The Lesson Of Not Commming Back? Does he enjoy my mayhem!?!

funny you post this after getting banned every single time you rejoin the SBB discord server when the executor notices how many braincells they're loosing by reading your crap


Dennis

Joined: Jan 27, 2005

"We are made of starstuff. ― Carl Sagan


Posted: Aug 18, 2019 08:55 PM    Msg. 28 of 32       
Quote: --- Original message by: Halonimator
Does he enjoy my mayhem!?!
No one does, except you apparently.


Kavawuvi
Joined: May 24, 2018

Brrrrrrring Ha!


Posted: Aug 19, 2019 10:38 PM    Msg. 29 of 32       
I guess since I made my announcement that I wouldn't be posting most updates in this topic, I've gotten a lot done with Invader.

Here's a brief, somewhat abridged rundown if anyone is still here who actually cares:

  • New program (invader-archive) which compresses all tags used to build a map into a .tar.xz archive you can distribute or store

  • New program (invader-bitmap) which generates bitmap tags (incomplete but can do most 2D textures, supports .png and .tga, and has a few mipmap algorithms to choose from)

  • New program (invader-crc) which spoofs the CRC32 of a map

  • New program (invader-resource) which compiles resource maps

  • New program (invader-reverse-dependency) which lists all tags that directly depend on a given tag

  • Fixed numerous issues with AI

  • Fixed numerous issues with building maps with scripts

  • Fixed numerous issues with shader tags



Pabeung
Joined: Dec 18, 2018

Oify


Posted: Nov 6, 2019 08:53 AM    Msg. 30 of 32       
Bruh can this compile OS stuff


Kinnet
Joined: Dec 27, 2013

FeelsGoodMan


Posted: Nov 6, 2019 02:57 PM    Msg. 31 of 32       
Quote: --- Original message by: Pabeung
Bruh can this compile OS stuff

nope, no plans to add os support according to the devs saddly :(


Kavawuvi
Joined: May 24, 2018

Brrrrrrring Ha!


Posted: Nov 9, 2019 07:42 PM    Msg. 32 of 32       
Quote: --- Original message by: Pabeung
Bruh can this compile OS stuff

Short answer: No, but some people have said they may be willing to add in the functionality for that.

Long answer: A while ago, I made a readme on the GitHub repository that had a FAQ. I think this is the question you're looking for: https://github.com/Kavawuvi/invader#can-invader-build-create-yelo-maps

For your convenience, I pasted that particular question here, too:
Quote:

Can invader-build create .yelo maps?

Officially, invader-build only creates maps for the Gearbox port of Halo on the PC. The .yelo file format is specific to Open Sauce, a mod of Halo Custom Edition. Therefore, the Invader project does not support it. However, this does not mean that you can't make a fork of Invader that supports it, and there are people who have said they were willing to do this.

Basically, the scope of the Invader project is for the Gearbox port of Halo: Combat Evolved on the PC, thus it targets the retail version, trial version, and Custom Edition. Of course, Custom Edition maps are generated by default because that's what most people play on, but you will find all of the tools will work for those other releases, too.

Open Sauce maps, on the other hand, are Custom Edition maps that use tag data definitions that differ from the PC release. For me, supporting these requires a non-trivial amount of time in regards to development and testing - time that I don't have that I'd be willing to spend on something that I ultimately won't receive any sort of compensation from.

I understand that Open Sauce maps do add features that are not available on the base game. As a result, it's possible that most people will prefer to use OS_tool.exe over invader-build, despite the fact that invader-build can do things the base tool.exe can't do, too. In fact, I've made my peace with that a long time ago when I first started this project.

That said, people have said they would be willing to put the time into making a version of Invader that supports Open Sauce. They are welcome to do that, but they will have to remain forks. I simply will not accept pull requests that add Open Sauce support, as, again, it would become my burden to test and develop for it, plus it would be outside the scope of Invader.

 

 
Previous Older Thread    Next newer Thread







Time: Thu November 14, 2019 8:34 PM 203 ms.
A Halo Maps Website