thecheeseman / iocod Goto Github PK

Hello there, I saw this and it really piqued my interest (as I am an avid mapper and modder for Call of Duty United Offensive). Thought I'd post a message to see how this project is going, and was wondering what the plans are regarding Singleplayer support?

I exclusively mod for Singleplayer. While I have spent basically over a decade exploiting the CoDUO engine and learning of its limitations (surprisingly can handle a lot of complexity compared to some of the later id Tech 3 games), I can see that expanding the capabilities of the engine to allow for even larger maps, more detail, and of course more scripting functions would further fulfil its potential, quite amazing to think the fact it is a id Tech 3 based engine, though it has also diverged so much.

Thought I'd share (or perhaps 'brain dump') some limitations and creative constraints that come to mind, from my experience, that could be addressed as part of ioCoD to take advantage of the 20 years of computer performance development since the engine was originally conceived:

1. Xmodel Level of Detail Culling
   Considering that the CoDUO engine allows for 2,045 visible xmodels in view at any given time, this does not consider the xmodel 'Low LoD Distance' which practically culls the xmodel beyond this distance (thus going from High->Medium->Low->Invisible/Culled). I believe this is something addressed in Call of Duty 2. Would make sense to also higher the limit of visible models alongside this.
2. Limited number of Weapon / Vehicle definition files (127)
   I believe there is a limitation on the number of Weapon definition files (and Vehicles), about 127, while this does sound like a large number, keep in mind the game already fills most of this with the various weapontypes (also the 'semi' / 'automatic' versions takes up an additional slot).
3. Unique Xmodels allowed to be loaded in a level (255)
   There is a limitation on the number of unique xmodels that can be loaded / precached into a level (255). Again, this number can easily be reached when dealing with various model attachments to character models in particular.
4. Level geometry
   While nothing specific here, I think it is obvious that being able to allow for higher limits on the key components of levels would be desired; such as entity limits, amount of brush geometry / terrain patches, increased size of level region (size), number of pathnodes, number of concurrent AI (I think it is limited to ~32 alive AI). Perhaps consideration of increasing the limits on lightmaps and shaders of geometry as well.
5. Q3map compiler and Radiant/Graydiant
   CoD and CoDUO use a fairly dated version of q3map, the map compiler. The newer Q3map2 has been developed for most id Tech 3 games, however support for Call of Duty has not been included as of yet. Not sure if you have plans to upgrade the map editors in addition to the engine code? I think Radiant / Graydiant could do with some updates to make it more user-friendly and aligned with some of the latest level editor functionality also (such as NetRadiant).
6. Number of Sound Channels
   Probably another obvious one is to consider expanding the number of concurrent sounds that can be played also, probably not as crucial though.
7. Vertices / polygon limit of xmodels
   Another one in terms of expanding the limitation on vertices / polygon allowance for xmodels. I don't generally meet these limits, though I think I have had some issues with converting XMODEL_EXPORT to the xmodel format because my model had a single texture applied to more than ~4,095 vertices.
8. Scripting
   While you can do so much with the level scripts, there could be so much more in terms of potential (and functions). One key thing is I feel like the minimum wait time on a while(1) loop is equivalent to 20fps or so (despite setting to wait 0.001), being able to have loops that respond on a frame-by-frame basis much more closely would make some results look far better and more smoother.
   It would also be great to have the ability to apply the left/right/top/bottom 'arc' restrictions to the player's view, as can be done in CoD4+ with the PlayerLinkTo functions (example: PlayerLinkToDelta( , , , , , , , )). Also integrating the script function to read if a particular key has been pressed would also be very useful (ButtonPressed( )).