Quote:
Originally Posted by gap
That's brilliant TDW 
I guess that making planes to taxi on carrier's deck would be too an hard task, if possible at all, but what about placing 4 bones on carrier's 3D model (two in front of the bow and two abaft the stern) that spawned aircraft would use respectively as spawning/despawning point and as first/last waypoint? This way, carrier-borne aircraft would always spawn/despawn in the same position respective to their parent unit, and they would follow a more realistical take off / landing path.
Is this feasible, or yet one more of my usual reveries?  |
Too complicated. The amount of assembly code needed to implement this would be probably about the same as current amount of code (just shy of 1Kb) or more. If I had the source code I would attempt it because I can write in C++ SO much easier (and it takes a hell of a lot less time to do!). Trust me I'd love to make this patch better than it already is but writing in assembly is very difficult.
Here's what I would have to do just to get the aircraft updated with the carrier's current position at all times:
- find everywhere new units are created and adjust the amount of memory asked for them to some bigger size
- create new code that accepts carrier as argument passed and takes carrier's current position and updates all planes spawned by that carrier
- create new code that allocates memory for storing aircraft spawned by carrier and code for adding/removing those aircraft from that memory and code for allocating/destroying this memory when it's needed/not needed
- hook into game end and destroy all memory created for each carrier (have to iterate over all game units and see if they are type of carrier and if so see if they have spawned any units)
- etc. etc.
In assembly this is a TON of code. Writing in C++ or C# it would be a snap.
You have to keep in mind it took me a little over 4 months to develop this carrier patch to where it is currently.
Here's the real kicker: you have to know what every object is and how to locate it in order to use it (and what methods it has and how to use those methods). I'd say half the development time of this patch was decoding dlls and act files just to learn how things worked and how to get to the objects I needed. Then I had to manipulate the game and call functions out of order to make the game do what I wanted it to do. No easy task especially when there are multiple arguments passed to each function!!!
I'm amazed that I wrote code that didn't crash the game once. That never happens...but in assembly you either know your objects and memory addresses or you don't - bugs are usually rare.