Forged Alliance Forever Forged Alliance Forever Forums 2011-11-30T13:29:02+02:00 /feed.php?f=2&t=280 2011-11-30T13:29:02+02:00 2011-11-30T13:29:02+02:00 /viewtopic.php?t=280&p=3819#p3819 <![CDATA[Re: Maybe its time to improve the moho engine?]]>
Within the gamedata folder you have all the information that fa needs to run on in there.

Well as we also know pilot been adding new files to that area and using the .faf extenstion to do this.
mount_dir(InitFileDir .. '\\..\\gamedata\\*.faf', '/')

well my idea is that within the Mohodata.scd only 501kb big we can change/alter or rewrite using parts of the current info within it as that does not bridge the copyright laws and would keep faf up and running.

And we could redirect fa gamedata folder so that faf can modify any of the data inthere and change.
By doing, (This is fafbin's supcomdatapath.lua)

Code:
path = {}

local function mount_dir(dir, mountpoint)
    table.insert(path, { dir = dir, mountpoint = mountpoint } )
end

local function mount_contents(dir, mountpoint)
    LOG('checking ' .. dir)
    for _,entry in io.dir(dir .. '\\*') do
        if entry != '.' and entry != '..' then
            local mp = string.lower(entry)
            mp = string.gsub(mp, '[.]scd$', '')
            mp = string.gsub(mp, '[.]zip$', '')
            mount_dir(dir .. '\\' .. entry, mountpoint .. '/' .. mp)
        end
    end
end

mount_contents(SHGetFolderPath('PERSONAL') .. 'My Games\\Gas Powered Games\\Supreme Commander Forged Alliance\\mods', '/mods')
mount_contents(SHGetFolderPath('PERSONAL') .. 'My Games\\Gas Powered Games\\Supreme Commander Forged Alliance\\maps', '/maps')
mount_dir(InitFileDir .. '\\..\\gamedata\\*.faf', '/') ~ Remove
mount_dir(InitFileDir .. '\\..\\gamedata\\*.scd', '/') ~ Remove
mount_dir(InitFileDir .. \\..\\fafgamedata\\*.scd, '/') ~ Add
mount_dir(InitFileDir .. '\\..\\fafgamedata\\*.faf', '/') ~ Add

mount_dir(InitFileDir .. '\\..', '/')


hook = {
    '/schook'
}



protocols = {
    'http',
    'https',
    'mailto',
    'ventrilo',
    'teamspeak',
    'daap',
    'im',
}


This then leaves us free to change any of the gamedata effecting fa without it effecting gpgnet's fa.

Statistics: Posted by Reddev32 — 30 Nov 2011, 13:29


]]>
2011-11-29T22:27:38+02:00 2011-11-29T22:27:38+02:00 /viewtopic.php?t=280&p=3814#p3814 <![CDATA[Re: Maybe its time to improve the moho engine?]]>

But I have to agrjfsk... agredkj... *takes a breath* agree with uber, the supcom2 and demigod versions of the moho engines are unusable, the complete different map format(that until now nobody got into) would just be one major problem, not to mention the amount of work to convert one of these games into fa.

Building fa based on the cryengine3 -> what uber wrote.

Anyway, the idea of improving the moho engine is...
object

Statistics: Posted by Karottenrambo — 29 Nov 2011, 22:27


]]>
2011-11-29T15:02:41+02:00 2011-11-29T15:02:41+02:00 /viewtopic.php?t=280&p=3811#p3811 <![CDATA[Re: Maybe its time to improve the moho engine?]]>
- Modifying an engine (SC2, demigod, etc) to work with FA will be nigh impossible. Even ignoring the legal issues (which would be enough to crush the project anyway), you would essentially be re-creating the game, perhaps even without any source to work from. FA is not a simple game. While such a thing isn't completely ruled out by the laws of physics, it would likely take many, many, many years to even come close to working, and then would likely be impossible to release due to the legal quagmire surrounding it.

- Creating FA from scratch (even using an engine such as Cryengine, unreal, etc) would not only be exceedingly difficult (remember that FA, bugs and all, was developed over a period of several years by a large, professional team), but, again, next to impossible to release in any way if it used FA's assets.

- Modding FA to work better is probably the most reasonable of the proposed ideas, but it will still be very difficult to do anything more than the most basic of improvements. The cost of hooking them may even outweigh any benefits, as I'm pretty sure there won't be much "low hanging fruit" as that would likely have already been fixed by GPG where possible. Lastly, there would still be some legal gray area surrounding it as you are technically modifying the the original source code by using any of the hooking techniques proposed.

Statistics: Posted by uberge3k — 29 Nov 2011, 15:02


]]>
2011-11-28T23:07:32+02:00 2011-11-28T23:07:32+02:00 /viewtopic.php?t=280&p=3807#p3807 <![CDATA[Re: Maybe its time to improve the moho engine?]]> They did this for supcom 2

What it instead of trying build a better engine we simply port FA to the Supcom 2 engine

Many modders have already ported over units and structures. to supcom 2 and vice versa. so getting the factions over should not be a problem (although It may not be possible to have 4 factions on the supom 2 engine)
The issues would be getting the the engine to reed FA map files and to not connect to steam
And of course the many legal issues behind this since you would either be giving FA owners a copy of the Supcom 2 engine or SC2 owners all the models textures and sound files from FA.

We could also consider the demigod engine since it two received changes from the FA one
and the CryEngine 3 which was released by the company for free.
The only issues these is that the Moho engine for supcom is designed to handle path finding for lots of units semi efficiently and these engines were not designed with this goal in mind. so there may be issues trying to get them to move 600 tanks across 50 km of terrain

However modifying any of these engines to run FA is still way simpler than trying to scratch build one capable of out performing an engine that GPG as yet to see the need to replace

Statistics: Posted by microwavelazer — 28 Nov 2011, 23:07


]]>
2011-11-28T15:41:24+02:00 2011-11-28T15:41:24+02:00 /viewtopic.php?t=280&p=3803#p3803 <![CDATA[Re: Maybe its time to improve the moho engine?]]>
Even with the source code, only fixes would be doable, as offloading AI work to the GPU or even a full engine rewrite could easily take a man-year or two to get it to work reliably. Same goes for graphics improvements beyond what can be achieved through better assets and textures.

That said... the following potential hacks seem to make sense to me:
  • enable loadlib in SupCom's Lua, which would allow us to do EVERYTHING we could sensibly want :twisted:
  • remove the occasional crippling bug (really, are there any?) - candidate is the sim speed autolimiting code which is somewhat bugged

Performance is fine, and with modern machines SupComFA runs at +5 or higher sim speed in every situation. Stability is good to fine.

Statistics: Posted by thygrrr — 28 Nov 2011, 15:41


]]>
2011-11-28T11:35:57+02:00 2011-11-28T11:35:57+02:00 /viewtopic.php?t=280&p=3795#p3795 <![CDATA[Re: Maybe its time to improve the moho engine?]]>

Statistics: Posted by Ze_PilOt — 28 Nov 2011, 11:35


]]>
2011-10-18T14:17:05+02:00 2011-10-18T14:17:05+02:00 /viewtopic.php?t=280&p=2339#p2339 <![CDATA[Re: Maybe its time to improve the moho engine?]]>
Ze_PilOt wrote:
If you are capable of hooking some functions, go ahead and try.

To be begin with something simple, maybe try to hook the functions that the engine is capable to receive from the server (sendNatPacket, ConnectToPeer, DisconnectToPeer, ....)


maybe (i think) have found a possibility to hook the most call functions without to RE, diss.. of the moho engine :P . I give a try tomorrow evening.

Statistics: Posted by arisg3 — 18 Oct 2011, 14:17


]]>
2011-10-18T11:10:58+02:00 2011-10-18T11:10:58+02:00 /viewtopic.php?t=280&p=2336#p2336 <![CDATA[Re: Maybe its time to improve the moho engine?]]>
To be begin with something simple, maybe try to hook the functions that the engine is capable to receive from the server (sendNatPacket, ConnectToPeer, DisconnectToPeer, ....)

Statistics: Posted by Ze_PilOt — 18 Oct 2011, 11:10


]]>
2011-10-18T11:03:10+02:00 2011-10-18T11:03:10+02:00 /viewtopic.php?t=280&p=2335#p2335 <![CDATA[Re: Maybe its time to improve the moho engine?]]>
Gowerly wrote:
Multithreaded Rendering is, weirdly, quite resource heavy.
You can try D3D Hooks, similar to the steam overlay, but I'm not sure you can influence anything that's trying to be drawn at this point, merely add new things.

as Ze_Pilot has said, any reverse engineering of the engine, will be completely illegal and we couldn't possibly support it. Even using Spring to make a new engine and using the Supcom Assets wouldn't be legal.

The only way we can have our own engine, would be to have our own game, and that's not our objective here.


I `d say at beginning "Maybe its time to improve the moho engine?" and yes i dont wanna have also a new engine but i wanna have some things that will help to boost this amazing game. With D3D Hooks i cannot implement a fast data stream outpout so that pathfinding calculations --in realtime for each one unit without the crash and go it happens now--go to the gpu.

Unfortunately only with RE or Diss.. is possible to take/earn the knowledge in a calculated amount of time what exactly moho does, and if you have the knowledge it's not difficult to writte a wrapper for the needed functions (just now Pathfinding)

I also wish a simulated land surface --later with climate variance--, simulated water effects, imagine a massive naval battle --possible with gpu/free shader code--.

http://www.youtube.com/watch?v=4G9anRoYGko&feature=related

http://www.youtube.com/watch?v=7cjorOe810o&feature=related

http://www.youtube.com/watch?v=E3ANHaajCPo&feature=related

http://www.youtube.com/watch?v=K1I4kts5mqc

http://www.youtube.com/watch?NR=1&v=-uavLefzDuQ

epic scale> http://www.youtube.com/watch?v=jL9BKTkTMY4&feature=related and

http://www.youtube.com/watch?v=BM7Pz7CgTnc&feature=related --Galactic War Pure--

Statistics: Posted by arisg3 — 18 Oct 2011, 11:03


]]>
2011-10-17T15:29:48+02:00 2011-10-17T15:29:48+02:00 /viewtopic.php?t=280&p=2307#p2307 <![CDATA[Re: Maybe its time to improve the moho engine?]]> You can try D3D Hooks, similar to the steam overlay, but I'm not sure you can influence anything that's trying to be drawn at this point, merely add new things.

as Ze_Pilot has said, any reverse engineering of the engine, will be completely illegal and we couldn't possibly support it. Even using Spring to make a new engine and using the Supcom Assets wouldn't be legal.

The only way we can have our own engine, would be to have our own game, and that's not our objective here.

Statistics: Posted by Gowerly — 17 Oct 2011, 15:29


]]>
2011-10-17T15:10:39+02:00 2011-10-17T15:10:39+02:00 /viewtopic.php?t=280&p=2306#p2306 <![CDATA[Re: Maybe its time to improve the moho engine?]]> http://itee.uq.edu.au/~csmweb/decompilation/disasm.html#sourcer

Another posibility is to use first, as basis the Spring opensource engine and modified it to what we wanna need. Unfortunately it lack the M$ directx rendering features. :roll:

Statistics: Posted by arisg3 — 17 Oct 2011, 15:10


]]>
2011-10-17T14:55:04+02:00 2011-10-17T14:55:04+02:00 /viewtopic.php?t=280&p=2303#p2303 <![CDATA[Re: Maybe its time to improve the moho engine?]]> http://forums.gaspowered.com/viewtopic.php?f=2&t=39740

Would be interesting to know how he has done it.

Statistics: Posted by Ze_PilOt — 17 Oct 2011, 14:55


]]>
2011-10-17T14:52:05+02:00 2011-10-17T14:52:05+02:00 /viewtopic.php?t=280&p=2301#p2301 <![CDATA[Re: Maybe its time to improve the moho engine?]]> Statistics: Posted by Moritz — 17 Oct 2011, 14:52


]]>
2011-10-17T14:45:57+02:00 2011-10-17T14:45:57+02:00 /viewtopic.php?t=280&p=2299#p2299 <![CDATA[Re: Maybe its time to improve the moho engine?]]> Of course, by using method 1, otherwise it would be against the EULA :roll:

Statistics: Posted by Ze_PilOt — 17 Oct 2011, 14:45


]]>
2011-10-17T14:44:37+02:00 2011-10-17T14:44:37+02:00 /viewtopic.php?t=280&p=2298#p2298 <![CDATA[Re: Maybe its time to improve the moho engine?]]> Statistics: Posted by FunkOff — 17 Oct 2011, 14:44


]]>