Guess after so many years, you still don't understand that everything is optional in Sapp, hence you can still run a vanilla-like server with Sapp, it's not different from Gandanur in this aspect.

Can you point out where this feature was requested on the forum because if it was, I must have overlooked it, otherwise I'd have implemented it already.

I simply didn't know it was broken since I never used it, and no one reported it either on the forum until it got fixed in UHMSO.
Edited by sehe on Aug 1, 2015 at 01:11 PM
Edited by sehe on Aug 1, 2015 at 01:12 PM

Sure sehe, np (and glad to be of service) check out this SAPP feature request (on your own SAPP Forum) here: http://xhalo.tk/forum/thread-342.html

Your reply posted on 2015. May. 27 was, "RE: checking how much time is left
It is now the part of the info command."

After we showed you it implemented in one of Realworld Guild's Servers.

BTW, I am aware that SAPP features can be disabled.

So am I correct in assuming you are teasing a game-changing feature for this new server without revealing it, simply because you're afraid that Sehe might rob you?

Otherwise please share...

Also, as I previously asked, would it be possible better sync up the weapon spawn times? So that they spawn at exact intervals instead of approximate ones?

He was asking for an event variable to be used in the event system, not as a feature like in the info command, so it's totally different.

And you can reveal your "top secret revolutionary feature", since I surely won't code a single line for Sapp for at least a month now. But I have the feeling that it will be something that can be done with Lua scripts already, so I doubt I'll implement it anyways.
Edited by sehe on Aug 1, 2015 at 02:31 PM

There are specific aspects to these new features which are still being developed and that remain as yet not finalised, so it would be unfair to describe such functionality in any fine detail. However yes, there is also a small percentage factor included about not wishing to reveal full functionality beforehand due to risks of cloning, and it's also certainly correct that much functionality can be programmed using lua scripts, but there are other aspects to this besides which rely on far more than just lua scripting alone.

Basically one of Halo's strongest features is by today's standards completely lagging behind possibilities which current technology permits and this one area alone concerns extended communication, and that it can be expanded to do other things. In fact the list is huge and almost endless.

So we could just say that it's about providing a framework for inter-server communication and leave it at that. Which is true, actually but in fact it's far more than simply that, it's about building upon Halo's own native communication to kick the game back into the 21st centuary.

Sounds perfect for integration with Zeus, ya??

SAPP loads itself into the server's address space as a module in the same way that many other components that Halo depends on do. It's not really as hacky as you make it sound.

Having an entirely different process with its own address space is not 'more legitimate'. It's a different approach that would make little sense for something like SAPP.
Edited by Btcc22 on Aug 1, 2015 at 11:04 PM

dang son. Like a fly to stink

The design approach we take with the UHMSOŽ Project Files is Modular, where Server Operators choose to add which specific Module(s) their particular server "Type" requires, and this method basically entails whether they host either a SAPP Server or a Non SAPP Server "Type".

Consequentially a SAPP Server would not benefit from (or require) the UHMSOŽ Efficiency Improvement Module (which also provides common SAPP functionality (like Game Time, Lead Status etc.) after all, there's no need to go re-invent the wheel (SAPP does what SAPP does perfectly well enough), but all Server Types could use the UHMSOŽ Extended Communications Module etc.

Also (similar to the ZEUS approach) there are far more ways then just one to skin a Cat, but just don't expect Schrodinger to help, because he doesn't care if the Cat is Dead or Alive (or simultaneously both Dead and Alive) until the lid is off the box!
Edited by Harbinger on Aug 2, 2015 at 04:48 AM

Harbinger, do you can add all UHMSO stuff to OS Dedicated servers??? :D
Edited by TheMegajd16 on Aug 2, 2015 at 02:13 PM

I don't know if you noticed but nobody ever uses OS to host servers.

No, actually, it doesn't. Strings.dll, which Haloceded loads with, but for some reason, doesn't really appear to use for anything, allows SAPP, Phasor, Gandanur and now UHMSO to modify strings.dll to load themselves as DLLs on demand.

Once loaded, they all modify EXISTING locations in the Halo executable to "hook" into the running code.

Codecaves are one way to achieve this, and those codecaves live in writable memory usually allocated by the server modification, not haloceded.exe - at least, in the case of Gandanur and Phasor. I haven't really researched what SAPP does, but they all seem to do the same thing, the same way.

Personally, I never understood the need for codecaves. A simple CALL/JMP FAR injected into the Halo executable does the same thing, and far more safely, as the destination is executable code, but NOT writable. Leaving code writable is never a good thing. Plus I never have to deal with copying all the code into those codecaves. While a CALL FAR is a few more bytes, implementing the extra bytes of overwritten code is a trivial matter.

The ONLY time you want writable+executable memory areas are when you have self-modifying code, and even then, it's better to write-protect it until you actually have to modify it.

Dang, hijacked my own thread.

This pretty much tells me how you have no clue about this topic.

I summon Btcc22, perhaps he can be bothered to explain.

Besides, Sapp's codecaves are read-only and AFAIK Phasor's too.
Edited by sehe on Aug 2, 2015 at 04:22 PM

You mean because I use a different definition of codecave, I don't know what I'm doing? If your definition of "codecave" is just an _asm block living in .text, well, then I use codecaves.

If your definition is a completely separate piece of code living in .data land somewhere, instead of .text where static code SHOULD be, well, then, we're at odds - but then, what else is new? Gandanur does this, for some reason. Just rechecked, and it does indeed leave code as RWE in data-land.

Just because I don't use the same term you do doesn't mean I don't know what I'm doing - it just means YOU don't know what I'm doing

As an aside, I just checked a dump of SAPP 9 I made a few months back, and you do indeed jmp directly into SAPP .text area, so ignore my previous comments about writable memory for codecaves. Looking through Phasor's source code, it also seems to use straight jmps into .text.

Again, Gandanur allocates writable memory and dumps it's codecaves there, for some strange reason.

Using that definition of "codecave" I guess I've been using them a long time. 30 years ago, I used to hack my IBM-XT's bios, and used pretty much the same approach. Dump a JMP to a different location further up in unused space in the EPROM image, write my code there, and then jmp back. Did that with various software as well. Back then, we didn't call it a "codecave". We just called it a "patch".

Kids these days, thinking they built something new - lol




Usually, "reverse engineering" of a delivered product goes against the "Right to use" license on/in the box. It's not "illegal", it just breaks the license, and so you have no "right" to use it anymore.


Edited by msalerno on Aug 2, 2015 at 07:06 PM
Edited by msalerno on Aug 2, 2015 at 07:08 PM

and if I want to create a server with yelo maps?

First of all, the definition of "code cave" has nothing to do with where the code cave itself is located. It is a small piece of code where you "transfer through" the execution from Halo to your own code then back to Halo (or vice-versa), hence the "cave". It is necessary to save the content of the registers and execute the original code that you replaced with the call/jmp. The CC itself can be hardcoded with the __asm keyword in your code, or can be in a small piece of allocated heap, it doesn't really change the definition. Usually the latter is used with automatic CC generation, such as M$'s detours library, which is less flexible, but useful if you don't want to bother with the asm part I mentioned above.

Secondary, no one said we built/invented sth new with CCs, tho overall we indeed did for Halo, unlike you.

And don't worry about hijacking your own thread, it's Halomaps, no one ever will come up with a decent idea (also since we kinda did everything that can be done in server side), perhaps you should just copy some of the core features of the existing server "tools".

Gosh, really? (where the hell is my sarcastic emoticon when I need it)



Don't be so self-centered, I was referring to whoever coined the term "codecave".

This method has been used for patching binaries for decades. It's nothing new.



Don't worry massa, if it's not implemented in SAPP, and not possible with LUA, it's never going to NEED implementing.

Got it.