Compilation on VS2017+

[optimus-code]

Hi

I was wondering if anyone else had successfully compiled under Visual Studio 2017 or above?

I do not have older versions installed on my system so in an attempt to build it at 2017 level (v141) with C++ 14, I receive multiple errors in the CL_InitRef ref function with the assignment of callbacks like "ri.FS_Read = FS_Read;" due to size_t to int conversion issues. Macro redefinition errors and such.

If anyone has any forks adjusted to work with vs2017+ please let me know. I'd love to try help with the project but I am quite partial to the newer VS IDEs.

[mohabhassan]

Hi, It works for me on vs2017 and 2019, at least for the server part. I don't know if client part compiles at. It probably doesn't. If so, that's on the todo list(maybe you can do it).

[optimus-code]

I've gotten a bit further, compiling game successfully but, cgame fails due to what appears to be a missing header file "tiki_local.h". I tried switching it over to the Tiki files that were there for but that only partly fixed the problem. Missing definitions for refEntity_t, refdef_t, baseshader_t for example.

As for openmohaa exe, i've got it down to an unresolved linker error for SDL so that's nearly building.

[Alex3474247]

Hello! Sorry for the late reply, but I also tried to compile Openmohaa with VC++ 2019 Community from misc\msvc12_13 folder, and only gamex86.dll compiles ok, the others failed to compile with 151 errors, that is too many for me to fix, I would understand if there were only 10-15 errors. Even some source files paths is incorrect in msvc12_13 projects (jpeg6, common, etc). Who is gonna fix it? This project is excellent and must not die, the original mohaa engine has serious speeding issue, the mouse cursor sticks to screen sides and it is impossible to play a game on my Windows 10 64 bit machine!

[miried]

Dear @optimus-code @Alex3474247

Good to see that people are still interested in this!

Unfortunately, the code has been dormant for a little too long, it seems. Fixing the errors and merging in ioquake3 progress is simply too much work to be done in too little time.

It would probably be the best idea to make a fresh start from current ioquake3, and continue development there. There are still quite some developers hanging out in the Discord, but no-one has started the effort to get it rolling. So any motivated fella is welcome! Whoever is interested in helping out, step forward 😄.

BTW: In an effort to learn some Rust, I've started working on a UI lib written entirely in Rust. Check it out at https://github.com/miried/mohrust if you're curious

[optimus-code]

Dear @optimus-code @Alex3474247

Good to see that people are still interested in this!

Unfortunately, the code has been dormant for a little too long, it seems. Fixing the errors and merging in ioquake3 progress is simply too much work to be done in too little time.

It would probably be the best idea to make a fresh start from current ioquake3, and continue development there. There are still quite some developers hanging out in the Discord, but no-one has started the effort to get it rolling. So any motivated fella is welcome! Whoever is interested in helping out, step forward 😄.

BTW: In an effort to learn some Rust, I've started working on a UI lib written entirely in Rust. Check it out at https://github.com/miried/mohrust if you're curious

I have been following OpenMOHAA for a long time, I used to be an active member of The Modding Theater, if you're old enough to remember, it used to be a MoH:AA modding gold-mine, unfortunately it has since disappeared.

I've previously looked at what it would entail to try re-implement OpenMOHAA into current ioQ3, to do that from the eyes of someone who wasn't involved in doing any work on OpenMOHAA I needed to do a full diff on the exact version OpenMOHAA was based on, I did manage to crack it but even then it is a mammoth task. As you know there's absolute ton of work gone into this project, it would require coordination to really see through and then still you have to account for differences between the ioQ3 versions.

The first thing to do in my opinion would be to isolate all the important data structures and functionality. But it's still a lot of work.

I remember seeing a video of this project a few years ago with a full running client and server, it just lacked the UI and some finer touches, but from what I gather the client side of this repo has gone into a state of disrepair whilst the server side is being fixed/improved?

I would be keen to help in any way I can but, from an individual perspective, it's much easier for me to re-write the entire engine, better yet in a high-productivity language like C#. That's where I reach an impasse because either way it's a huge task for one person so I can't justify spending the time on it as much as I want to.

I've already wrote a prototype in C# that does FAKK2 UI almost perfectly, renders levels, terrain and patches, has a cvar and command system like Quake engines and can plug into Unity, Urho3D, MonoGame etc. But to do a serious project is another thing entirely.

I'll check out your mohrust project for sure!

[miried]

The first thing to do in my opinion would be to isolate all the important data structures and functionality. But it's still a lot of work.

Yes, I think no matter how we approach it, there's no way around it being quite some work. But your message 13 years after this project was started proves that there is potential to move it forward.

I would be keen to help in any way I can but, from an individual perspective, it's much easier for me to re-write the entire engine, better yet in a high-productivity language like C#. That's where I reach an impasse because either way it's a huge task for one person so I can't justify spending the time on it as much as I want to.

I understand your reasoning. It's also why I started to work on a Rust implementation (I'm learning the language so it's not in best shape, but it's something at least). Some features of modern languages could help with implementing some stuff way faster.

However, I think it's much more efficient to join forces, and find a common ground (IMO that would be ioquake3 engine). I think in the end, it's about the project management, not the technical challenges.

I've already wrote a prototype in C# that does FAKK2 UI almost perfectly, renders levels, terrain and patches, has a cvar and command system like Quake engines and can plug into Unity, Urho3D, MonoGame etc. But to do a serious project is another thing entirely.

That sounds pretty cool! Do you have the code on github?

[inequation]

Guys, I just wanted to point out that this project originally started with the idea of taking ioq3 and augmenting it with stuff needed to run MoHAA, and it stalled pretty quickly. The latest efforts by Ludovic, Ley0k and mohabhassan breathed new life into it. I think it would be unwise to squander it and it should actually be fixed instead.

As much as I like Rust, I really don't think reimplementing everything and the world in it is a good way to accomplish things, @miried. ;)

[smallmodel]

In the future the project should start moving into C++17 (or above) instead. With C++, renderer, sound, client, server, network and others can be decoupled into multiple classes/subclasses and modules so that the user could for example use another sound or renderer system, and also join any mohaa server (AA/SH/BT) by having multiple network modules (mohue can connect to multiple protocols thanks to OOP). The game code is pretty advanced and requires Vehicle, and SH/BT features like radar, animated farplane, ToW/Liberation, vote, and a few more things. In this case, MAC binaries from Aspyr will help because they provide symbols. Current plan is to implement sound, uilib, renderer and cgame, then move on to using BT 2.40 code and maybe merge cgame/gamex into one executable file (should be static libs rather than shared).

[miried]

I think it would be unwise to squander it and it should actually be fixed instead.

As I said, whoever wants to fix it, can step forward.

As much as I like Rust, I really don't think reimplementing everything and the world in it is a good way to accomplish things, @miried. ;)

The existing solution is totally fine as long as it's in a workable state. In absence of that, I do believe exploring alternative solutions can accomplish things, though. You must always use developer resources as best as possible and that is a wasted effort if your onboarding is not zero, but negative. As for my Rust project, call it a yak shaving of some sort. It will be useful in some way (perhaps not here, I see how a language change would be an impediment).

[Crazy-P]

@miried

Someone already convertedall of ioquake last year to Rust by using C2Rust. A nice read. https://immunant.com/blog/2020/01/quake3/

[optimus-code]

Guys, I just wanted to point out that this project originally started with the idea of taking ioq3 and augmenting it with stuff needed to run MoHAA, and it stalled pretty quickly. The latest efforts by Ludovic, Ley0k and mohabhassan breathed new life into it. I think it would be unwise to squander it and it should actually be fixed instead.

As much as I like Rust, I really don't think reimplementing everything and the world in it is a good way to accomplish things, @miried. ;)

I agree, I was simply mentioning that from a personal perspective, I'd love to help but the task is too big for one person in its current state - especially if they have had no involvement in the code-base as of yet. Being able to compile without issues would be a step in the right direction; but I encounter the various issues above with missing TIKI files etc.

I don't know how or if the current team of contributors co-ordinate but this project would gain more traction if it was more organised. This is not a criticism but a suggestion from someone who really supports the advancement of openmohaa.

I would like to assist in any way that I can but a blocker for that at the moment is not being able to get a runnable build of the client so that I can test/proto-type code.

[inequation]

I completely agree with @miried that the challenges that this project is facing are of the project management kind, not technical. ;) Unfortunately, @Ley0k, your reply is symptomatic:

In the future the project should start moving into C++17 (or above) instead. With C++, renderer, sound, client, server, network and others can be decoupled into multiple classes/subclasses and modules so that the user could for example use another sound or renderer system, and also join any mohaa server (AA/SH/BT) by having multiple network modules (mohue can connect to multiple protocols thanks to OOP). The game code is pretty advanced and requires Vehicle, and SH/BT features like radar, animated farplane, ToW/Liberation, vote, and a few more things. In this case, MAC binaries from Aspyr will help because they provide symbols. Current plan is to implement sound, uilib, renderer and cgame, then move on to using BT 2.40 code and maybe merge cgame/gamex into one executable file (should be static libs rather than shared).

These should not be goals for a game recreation project like this. What you should be doing first instead is recover a working codebase, with bug-for-bug compatibility with the old binaries - even if you don't like its language standard version, or its DLL/executable structure - and only once that objective is completed, and there is no longer a threat of the code getting lost to history, should you start thinking about bugfixing and/or making it prettier.

In a perfect world, there would also be automated tests to make sure that the new, prettier code still produces the same result. The C2Rust project mentioned by @Crazy-P actually implements the same principles, just the source and target codebases are different.

The downside of this is of course that it's not as exciting, and devs are tempted to do more satisfying work. ;)

[razorapid]

My goal is to restart the project and give it clear guidelines under which everyone will be able to contribute. It takes time, however. I'd like to set it up around clear milestones and small enough tasks so the project is self-managing to a degree.

We've talked about it a bit with @miried

So currently I see two options - there is some individual who is willing to take initiative, sink their own time to learn current code base and clean it up and offer a patch/fork, or there isn't one and everyone waits for someone else to take that initiative.

I'm willing to take that initiative but I have limited time I can spend on it right now.

EDIT:

To give more context - I want to create a hollow template project that will have all structures and function/methods signatures of the original game. Then create milestones around modules/subsystems or vertical pieces of functionality and tasks for implementing function by function to reach 1:1 compatibility with original binaries.

I want to always keep it in a compilable state, preferably with a set of unit tests.

Only then we can refactor the code base and fix bugs found in original game.

I don't know if I'll proceed with that plan under openmohaa umbrella. This is to be decided by the rest of you guys.

If I get a green light, I'd like to move current code base to different branch/repo and start afresh.

This is of course my idea for project development and management. It may be not the best one. If anyone else has other ideas, let's share them so we can discuss what we find suitable to move things forward.

[optimus-code]

My goal is to restart the project and give it clear guidelines under which everyone will be able to contribute. It takes time, however. I'd like to set it up around clear milestones and small enough tasks so the project is self-managing to a degree.

We've talked about it a bit with @miried

So currently I see two options - there is some individual who is willing to take initiative, sink their own time to learn current code base and clean it up and offer a patch/fork, or there isn't one and everyone waits for someone else to take that initiative.

I'm willing to take that initiative but I have limited time I can spend on it right now.

EDIT:

To give more context - I want to create a hollow template project that will have all structures and function/methods signatures of the original game. Then create milestones around modules/subsystems or vertical pieces of functionality and tasks for implementing function by function to reach 1:1 compatibility with original binaries.

I want to always keep it in a compilable state, preferably with a set of unit tests.

Only then we can refactor the code base and fix bugs found in original game.

I don't know if I'll proceed with that plan under openmohaa umbrella. This is to be decided by the rest of you guys.

If I get a green light, I'd like to move current code base to different branch/repo and start afresh.

This is of course my idea for project development and management. It may be not the best one. If anyone else has other ideas, let's share them so we can discuss what we find suitable to move things forward.

I think this is also where there needs to be an agreed upon set of terms for how things should be implemented. My personal stance differs from most in this project I believe. I think we should follow by OpenMW's example and just develop functionality not to be a 1:1 identical match but to be a best approximation, and then let people with reverse engineering skill workout the finer details as and when they can. This allows you to develop functional code more rapidly without worrying about spending your whole day in IDA or ollydbg trying to reverse engineer functionality you could approximate with just having a crack at it. The core parts will need to be from reverse engineered code but most work wouldn't need to be 1:1 which is where the difficulty lies.

The guys who have grafted to get openmohaa where it is, have done most of the hard work already in terms of reverse engineering so it's really a case of getting things functional.

My opinion is that the best method would be to create a new branch based off current ioQ3, undertake a very big project of transpiling functionality over; whilst ensuring you have a runnable/workable build at all times. No massive refactors or feature creep.

I think a good way to start would be to map out cards on a kanban of the functionality needed in order to satisfy compatibility with mohaa (e.g. what is needed to run maps, and the tasks involved in that) that way people can just take up whatever takes their fancy and there's always tasks available for people to take on. Anyway I'm not really anything to do with openmohaa itself so it's not a decision I can make.

[razorapid]

I differ from most of you guys when it comes to basing OPM on current ioquake3 source code, because it comes with it's own set of bugs and new features so it has an even bigger scope/surface, unless we don't care about regression we may potentially introduce to those new features while adapting it to run MoHAA.

In the approach proposed by me - everyone can fill in blanks with approximations and it even enables clean-room approach (with the exception of function signatures and structures) if people with RE skills provide BDD/ATDD-style unit tests based on their research and others implement functions to adhere to given specifications.

[optimus-code]

I differ from most of you guys when it comes to basing OPM on current ioquake3 source code, because it comes with it's own set of bugs and new features so it has an even bigger scope/surface, unless we don't care about regression we may potentially introduce to those new features while adapting it to run MoHAA.

In the approach proposed by me - everyone can fill in blanks with approximations and it even enables clean-room approach (with the exception of function signatures and structures) if people with RE skills provide BDD/ATDD-style unit tests based on their research and others implement functions to adhere to given specifications.

Sorry to bump the post again. Just thought I'd add my two cents. I actually have no preference to which base a project would use, it was my understanding ioquake3 is the most mature and stable q3 client so that's why it has been chosen.

If the concern is about having to work with an iteration of the engine that is moving away from what MoH:AA was based on I'd also note that it's a moot point when you consider the fact MoH:AA itself is based on the Heavy Metal FAKK2 engine, which itself has a load of modifications from base Q3. Either way there are fundamental changes that would need to come into play in order to support the added functionality any base provides as well as the added functionality from FAKK2 and MOHAA.

[razorapid]

If base is irrelevant, why would we see a need to rebase openmohaa onto current ioquake3 engine, especially if we're ok with the fact that openmohaa will diverge sooner or later. One could as well fix current compilation issues and continue from where we are now.

Unless we actually care about basing openmohaa on ioquake3 because of new features and fixes, but then I'd say we need to take care not to break any existing ioquake3 feature while adding support for MoHAA and we should do regression tests and rebase the project periodically onto upstream ioquake3 engine.

I've only stated that I'm not a fan of the latter approach and anything inbetween (borrowing bugs from current ioquake3's master and never updating again)

[inequation]

My gripe with approximating functionality, as opposed to reverse engineering it, is what each respective method has accomplished. OMoHAA started with the idea of me approximating MoHAA features on top of ioq3, and it didn't go much farther than adding a few MoHAA BSP features. The guys doing the reverse engineering have something that is at least partially functional, even if not on your platform of choice.

[optimus-code]

If base is irrelevant, why would we see a need to rebase openmohaa onto current ioquake3 engine, especially if we're ok with the fact that openmohaa will diverge sooner or later. One could as well fix current compilation issues and continue from where we are now.

Unless we actually care about basing openmohaa on ioquake3 because of new features and fixes, but then I'd say we need to take care not to break any existing ioquake3 feature while adding support for MoHAA and we should do regression tests and rebase the project periodically onto upstream ioquake3 engine.

I've only stated that I'm not a fan of the latter approach and anything inbetween (borrowing bugs from current ioquake3's master and never updating again)

Whatever action needs to happen in order to get the client off the ground and functional in my opinion. I'm not really proposing anyone do any more than the minimum viable product so that a playable client. exists

My gripe with approximating functionality, as opposed to reverse engineering it, is what each respective method has accomplished. OMoHAA started with the idea of me approximating MoHAA features on top of ioq3, and it didn't go much farther than adding a few MoHAA BSP features. The guys doing the reverse engineering have something that is at least partially functional, even if not on your platform of choice.

And that is why the project is where it is (Not to take light on the hard work already put in) but it's been in a state of despair for years because no one wants to or can take up the mantle of getting compilation and the UI etc sorted. This would be progressed quicker if someone with prior experience in the codebase could assist or direct things.

I would be happy to help progress things but I'm not about spending hours attempting to disassemble game functions, I've had my share of experience with that in the past and it's not something I want to spend my limited time on, especially when a lot of functionality can just simply be re-created, it makes no logical sense to me. I think if it's functionally the same then it doesn't really matter, I don't see why you would need to have a 1:1 replica of the original engine to be compatible, as long as the core components and protocols are reverse engineered or clean-room implemented to be identical then you should be all good.

[inequation]

I would be happy to help progress things but I'm not about spending hours attempting to disassemble game functions, I've had my share of experience with that in the past and it's not something I want to spend my limited time on, especially when a lot of functionality can just simply be re-created, it makes no logical sense to me. I think if it's functionally the same then it doesn't really matter, I don't see why you would need to have a 1:1 replica of the original engine to be compatible, as long as the core components and protocols are reverse engineered or clean-room implemented to be identical then you should be all good.

You haven't modded the game, have you? :) MoHAA isn't exactly an engineering marvel, its scripting and code is held together by the proverbial duck tape and saliva (and it's not all 2015's fault, mind you). Game functionality actually largely depends on the quirks and bugs being there to function correctly, thanks to the accumulated cruft of legacy workarounds, and your "core components and protocols" required to keep in bit-for-bit compatibility cut through the entire tech stack of the game.

I have the opposite experience of trying to reimplement old code as "approximated functional equivalents", and it always ended in a long tail of confusing and frustrating debugging sessions, because there are always edge cases you just won't handle the exact same way as the original.

I have no claim to steering this project one way or another, BTW, just sharing what I would consider the shortest path to having a cross-platform MoHAA clone implementation that can then be further improved upon and expanded.

[optimus-code]

I would be happy to help progress things but I'm not about spending hours attempting to disassemble game functions, I've had my share of experience with that in the past and it's not something I want to spend my limited time on, especially when a lot of functionality can just simply be re-created, it makes no logical sense to me. I think if it's functionally the same then it doesn't really matter, I don't see why you would need to have a 1:1 replica of the original engine to be compatible, as long as the core components and protocols are reverse engineered or clean-room implemented to be identical then you should be all good.

You haven't modded the game, have you? :) MoHAA isn't exactly an engineering marvel, its scripting and code is held together by the proverbial duck tape and saliva (and it's not all 2015's fault, mind you). Game functionality actually largely depends on the quirks and bugs being there to function correctly, thanks to the accumulated cruft of legacy workarounds, and your "core components and protocols" required to keep in bit-for-bit compatibility cut through the entire tech stack of the game.

I have the opposite experience of trying to reimplement old code as "approximated functional equivalents", and it always ended in a long tail of confusing and frustrating debugging sessions, because there are always edge cases you just won't handle the exact same way as the original.

I have no claim to steering this project one way or another, BTW, just sharing what I would consider the shortest path to having a cross-platform MoHAA clone implementation that can then be further improved upon and expanded.

LOL sure I've never modded the game.... Making baseless assumptions like that isn't really wise is it? How does the saying go? "Never assume, it makes an ass out of both me and you..."

I wouldn't under-estimate the complexity of a game engine consisting of around 200,000 lines of code either, it doesn't have to be a technical marvel, the fact is; it's a monolithic project that is big enough to need more than one developer sifting through it.

The results of your approximated code are born of your effort. If you don't plan and structure it then it's going to be chaotic and grow out of control. This is just the nature of development.

The things I said were generalised for the sake of argument but you seem more focused on being patronising, I don't have time to deal with such childish behaviour.

Anyway if that's what this community is about, good luck!

[inequation]

I did not mean to patronise, I'm sorry it came across this way. Those were simply counter-arguments, also for the sake of discussion, and the part about modding was just me reminiscing about the time I spent studying MoHAA's scripts and the scant documentation released with the "SDKs" those 10-15 years ago.

[razorapid]

@inequation has a point that in many places approximation won't be enough. Maybe it could be worded differently.

The other thing is that this project is open for contributions, but during all those years no one really came with anything (except Ley0k and Ryback). For example fixes in a project structure or compilation issues. This includes me. I haven't contributed a single character to this repository myself.

To me it seems like everyone hopes someone else will do the hard work :)

As I said before - I'm willing to do the hard work, but if I do - I'd rather do it my way, with options open for others to chime in. There is no need to vote for my idea etc. because I'll start it anyway, even if I'll work on it alone.

[optimus-code]

I did not mean to patronise, I'm sorry it came across this way. Those were simply counter-arguments, also for the sake of discussion, and the part about modding was just me reminiscing about the time I spent studying MoHAA's scripts and the scant documentation released with the "SDKs" those 10-15 years ago.

Apologies for my misinterpretation then. I can fully appreciate where you're coming from with regards to the old school modding scene and the SDKs released.

@inequation has a point that in many places approximation won't be enough. Maybe it could be worded differently.

The other thing is that this project is open for contributions, but during all those years no one really came with anything (except Ley0k and Ryback). For example fixes in a project structure or compilation issues. This includes me. I haven't contributed a single character to this repository myself.

To me it seems like everyone hopes someone else will do the hard work :)

As I said before - I'm willing to do the hard work, but if I do - I'd rather do it my way, with options open for others to chime in. There is no need to vote for my idea etc. because I'll start it anyway, even if I'll work on it alone.

This is not a controversial point which is why I mentioned "core functionality" needing to be reverse engineered vs approximation. I just wanted to stress the point that you can get to where you want to go quicker by not going to an obsessive level with producing 1:1 reverse engineered code in every instance. I take the pragmatic view, do the bare minimum to get it functioning and work from there.

I am not worried about getting my hands dirty but it's hugely inefficient to have someone with no prior experience in the codebase try and solve this problem. You have a resource available in the form of the knowledge and experience the contributors have developed over the years, this would be the best way to approach resolving these issues IMO. Otherwise you are stabbing in the dark.

This is why I mentioned previously from a personal perspective, I'd sooner write an engine from scratch than spend any more time trying to resolve this issue (having already spent a good portion of time just trying to get the project to build and run on Windows with VS2019 to no avail - every time I fixed a problem 2 more problems would surface)

I think it would make sense to pool all resources if possible, it's a shame that there are potentially multiple projects trying to achieve almost the same thing.

[miried]

I think we all agree that the project got into a deadlock situation. I'm not sure whether any of the different approaches is to blame (they both have strengths and weaknesses), or just various other factors. I'm with @razorapid in the sense that everyone should do it the way they see fit.

I'd rather see someone make an effort, even if not supported by the majority, than no effort at all. Maybe it's just a bootstrap problem that someone needs to get some momentum and the others can chime in. No matter which approach.

[smallmodel]

Closing this issue in favor of issue #28.