BrawlBox v0.78

[uyjulian]

I guess it's time that the newer BrawlBox programs should be released this week.

https://github.com/libertyernie/brawltools

stop complaining, last update was 2 days ago (as of this post)

[Brandondorf9999]

https://github.com/libertyernie/brawltools

stop complaining, last update was 2 days ago (as of this post)

It's not a complaint, it's a mind thing I thought about when it should be here. I will have to try to compile it myself since I have Visual Basic on my computer. If it compiles the correct way, I will post it here.

[BlackJax96]

If it compiles the correct way, I will post it here.

And if you do, I will warn you. This is literally a warning warning.

We choose to release when we do because we feel that the program is in a stable enough state for everyone to use, and it's none of your business posting an incomplete build here like some kind of hero. It's our work, not yours, and we will release it when it is ready.

[uyjulian]

Well, I found some problems when I was compiling with Mono, but I fixed them.

[Brandondorf9999]

Well, I found some problems when I was compiling with Mono, but I fixed them.

Visual Studio is the easy way to compile it without these errors. Although it can detect errors when compiling if any code like that exists.

[BlackJax96]

Well, I found some problems when I was compiling with Mono, but I fixed them.

Merge your changes yo!

I just pushed some stuff like literally a minute ago, maybe I fixed something you came across.

Just be careful changing pointer operations, one of the previous fixes for mono broke some code that wrote CHR0 and SRT0 animations.

Visual Studio is the easy way to compile it without these errors. Although it can detect errors when compiling if any code like that exists.

Mono can compile for platforms other than just Windows, so it's a little bit different.

[uyjulian]

Merge your changes yo!

I just pushed some stuff like literally a minute ago, maybe I fixed something you came across.

Just be careful changing pointer operations, one of the previous fixes for mono broke some code that wrote CHR0 and SRT0 animations.

Mono can compile for platforms other than just Windows, so it's a little bit different.

What should I convert to, System.VoidPtr or byte*?

[Sammi Husky]

Visual Studio is the easy way to compile it without these errors. Although it can detect errors when compiling if any code like that exists.

Please, i request that you do not post development builds in this thread.

We're nearing release now anyways, so please let others wait the short amount of time left. If people get the dev build now, it will be unfinished, and many will likely not come get the completed version afterwards. I would like for people to get the most complete, most functional build of our work rather than an early development build that will likely be broken, all over a matter of time as short as this.

That being said, you can compile the code yourself if you'd like. Just please, don't post it here. If anybody wants the dev build, compile it yourself or PM Brandon here. The less confusion around this release the better.

[BlackJax96]

What should I convert to, System.VoidPtr or byte*?

VoidPtr works the same as byte*, so either or.

Here's some examples of what does and doesn't work.

Good:
int offset = 0x10;
VoidPtr address2 = (VoidPtr)address + offset;

Good:
int offset = 0x10;
byte* address2 = (byte*)address + offset;

Bad:
int offset = 0x10;
buint* address2 = (buint*)address + offset; //increments by 0x40 instead

Good:
int offset = 0x4;
buint* address2 = (buint*)address + offset; //buint increments by four bytes, and 0x10 / 0x4 is 0x4

Good:
VoidPtr address;
buint* otherAddress;
int offset = (int)address - (int)otherAddress; //By casting to int, you get the raw address value so the pointer type doesn't matter

[uyjulian]

VoidPtr works the same as byte*, so either or.

Here's some examples of what does and doesn't work.

Good:
int offset = 0x10;
VoidPtr address2 = (VoidPtr)address + offset;

Good:
int offset = 0x10;
byte* address2 = (byte*)address + offset;

Bad:
int offset = 0x10;
buint* address2 = (buint*)address + offset; //increments by 0x40 instead

Good:
int offset = 0x4;
buint* address2 = (buint*)address + offset; //buint increments by four bytes, and 0x10 / 0x4 is 0x4

Good:
VoidPtr address;
buint* otherAddress;
int offset = (int)address - (int)otherAddress; //By casting to int, you get the raw address value so the pointer type doesn't matter

Thanks, I'll keep that in mind.

[Brandondorf9999]

Please, i request that you do not post development builds in this thread.

We're nearing release now anyways, so please let others wait the short amount of time left. If people get the dev build now, it will be unfinished, and many will likely not come get the completed version afterwards. I would like for people to get the most complete, most functional build of our work rather than an early development build that will likely be broken, all over a matter of time as short as this.

That being said, you can compile the code yourself if you'd like. Just please, don't post it here. If anybody wants the dev build, compile it yourself or PM Brandon here. The less confusion around this release the better.

Hm, is it possible for people to be seeing an update message saying that the previous version is up to date like this?:

[uyjulian]

Hm, is it possible for people to be seeing an update message saying that the previous version is up to date like this?:

yes

[Brandondorf9999]

yes

Do they want most people seeing this like any other program or not?

[BlackJax96]

Do they want most people seeing this like any other program or not?

Isn't this feature self-explanatory?

The only reason it shows the past version is because there's no release on the repo that has a version greater or equal.

[Sammi Husky]

Your seeing that, because the latest release's version number is different from the one in the development build. That's a given, since we haven't released the new version yet. This won't happen to people who get the released version, since they're version number won't be ahead of the latest release

Isn't this feature self-explanatory?

The only reason it shows the past version is because there's no release on the repo that has a version greater or equal.

damn! Ninja'd! :P