Jump to content
XCOMUFO & Xenocide

Feasability Of Adding Support For Tanks


Recommended Posts

Hi all,

Well, if there was one thing that I loved from UFO, it was blasting the enemy with a floating plasma tank. So I was thinking about what it would take to get these things working in UFO2000.

The nicest, most object oriented approach is to create a base class that is common to both soldiers and tanks (say squadmember), then have soldier and tank derived from that. However, soldier is referenced in so many places in the code, this would just break too many things. (trust me, I tried!)

The solution which would probably cause the least trouble would be to just modify the soldier class to add an extra boolean field for whether or not the unit is a tank. (or heavy weapons platform, what's the correct terminology?) Obviously quite a bit of code would need to change to reflect the fact that the tank cannot carry equipment, cannot be panicked etc, but this seems pretty easy. What seems more difficult is accounting for the fact that the tank is of size 2x2, so finding a route is harder, and the code for occupying a cell and being shot at would need non-trivial changes.

With modifying the soldier class to allow for tanks, should it go in the class, or in the UNITDATA struct? What is the purpose of this structure anyway? Compatibility with original game data, being passed to the character editor or what?

Finally, would making such major modifications to the game be likely to break compatibility with opponents playing with previous versions? If so, would it be a good idea to implement a feature whereby each client specifies the minimum build number with which is is compatible, and refuse to connect with an opponent running a lower build?

Thoughts anybody?????

Dave
Link to comment
Share on other sites

[quote name='Shifty Dave' date='May 1 2006, 05:14 AM']Hi all,

Well, if there was one thing that I loved from UFO, it was blasting the enemy with a floating plasma tank.  So I was thinking about what it would take to get these things working in UFO2000.

The nicest, most object oriented approach is to create a base class that is common to both soldiers and tanks (say squadmember), then have soldier and tank derived from that.  However, soldier is referenced in so many places in the code, this would just break too many things. (trust me, I tried!)

The solution which would probably cause the least trouble would be to just modify the soldier class to add an extra boolean field for whether or not the unit is a tank. (or heavy weapons platform, what's the correct terminology?)  Obviously quite a bit of code would need to change to reflect the fact that the tank cannot carry equipment, cannot be panicked etc, but this seems pretty easy.  What seems more difficult is accounting for the fact that the tank is of size 2x2, so finding a route is harder, and the code for occupying a cell and being shot at would need non-trivial changes.

With modifying the soldier class to allow for tanks, should it go in the class, or in the UNITDATA struct?  What is the purpose of this structure anyway?  Compatibility with original game data, being passed to the character editor or what?

Finally, would making such major modifications to the game be likely to break compatibility with opponents playing with previous versions?  If so, would it be a good idea to implement a feature whereby each client specifies the minimum build number with which is is compatible, and refuse to connect with an opponent running a lower build?

Thoughts anybody?????

Dave
[right][post="153419"]<{POST_SNAPBACK}>[/post][/right][/quote]

I agree HWP, both tanks, flying, whatever should be implemented. Along with a mission planner option to turn them off.

Now for the boring stuff;

Yes, the soldier class is pretty much used everywhere and is very closely related to a lot of things. Although, I think we should keep in mind that tanks would not carry equipment, it's weapon being preset when coding the unit (LUA).

This would allow for model variants. (similar to different armor) that'd change the weapons for example.

Since currently, the game would not make much differences between a soldier and a HWP, the soldier class could be used with the said boolean. Maybe Serge could give you better hints on this.

Also, it would be important to plan ahead for new HWP sizes. 2x2x2 or even 6x3x4 for a more extreme example. [u]This should be defined in unit's LUA.[/u] Such new sizes will allow for more versatility, which is very important.

[u]I can't stress this enough, it's very important that new units [b]stop being hard-coded[/b] and be customizable from LUA. Considering LUA doesn't make it much harder to program and allows for maximum scalability. HWP implementation should reflect this.[/u] Edited by nachtwolf
Link to comment
Share on other sites

[quote name='nachtwolf' date='May 2 2006, 08:10 AM']Also, it would be important to plan ahead for new HWP sizes. 2x2x2 or even 6x3x4 for a more extreme example. [u]This should be defined in unit's LUA.[/u] Such new sizes will allow for more versatility, which is very important.

[u]I can't stress this enough, it's very important that new units [b]stop being hard-coded[/b] and be customizable from LUA. Considering LUA doesn't make it much harder to program and allows for maximum scalability. HWP implementation should reflect this.[/u]
[right][post="153430"]<{POST_SNAPBACK}>[/post][/right][/quote]

Okay, that all sounds sensible to me. So in keeping with this philosophy, perhaps it would be best to add a field indicating that the unit cannot be panicked (and in fact has no mental stats at all), plus some fields indicating the x, y and z sizes of the unit. These would all be set by the LUA, and the C code wouldn't actually know the difference between a tank and a soldier, it would just operate according to these fields.

The main question I can see is that it's not so clear how to define the x, y and z coordinates of a unit. Maybe it should be the bottom, south-east corner of the unit or something. Some sort of new code would be required to test whether or not a unit is occupying a square, and this would need to be incorporated into all the appropriate code for movement, shooting so on.

I guess what I really want to know is would it be worth the effort of making these changes? Are other people making changes to these areas of code, so would it cause too many conflicts? If it's all too much trouble, I'd rather find that out now, instead of after spending lots of time on the problem!
Link to comment
Share on other sites

[quote name='nachtwolf' date='May 2 2006, 08:10 AM'][u]I can't stress this enough, it's very important that new units [b]stop being hard-coded[/b] and be customizable from LUA. Considering LUA doesn't make it much harder to program and allows for maximum scalability. HWP implementation should reflect this.[/u]
[right][post="153430"]<{POST_SNAPBACK}>[/post][/right][/quote]

Well, I've had a bit of a look at the code, and I now have a much better idea of the relationship between lua, xcom2000 and xcom data files.

I can see that implementing new units via the lua would be a much better way to go, and that adding any more hard coded units would just make the conversion to lua more difficult.

My question is, what is the status of this lua API for units, and who is working on it? Allowing for tanks would clearly involve extending this API, so clearly the priority should be for it to be stable and working for all the current units before worrying about new ones which stuff up everything. I would be willing to work on LUAfying the existing code, but I would need to be filled in on who has done (and is doing) what, as it's a little hard to figure out from the mantis logs.

PS: does anyone have a tool for quickly and easily viewing contents of .pck files?
Link to comment
Share on other sites

[quote name='Shifty Dave' date='May 2 2006, 07:57 AM'][quote name='nachtwolf' date='May 2 2006, 08:10 AM'][u]I can't stress this enough, it's very important that new units [b]stop being hard-coded[/b] and be customizable from LUA. Considering LUA doesn't make it much harder to program and allows for maximum scalability. HWP implementation should reflect this.[/u]
[right][post="153430"]<{POST_SNAPBACK}>[/post][/right][/quote]

Well, I've had a bit of a look at the code, and I now have a much better idea of the relationship between lua, xcom2000 and xcom data files.

I can see that implementing new units via the lua would be a much better way to go, and that adding any more hard coded units would just make the conversion to lua more difficult.

My question is, what is the status of this lua API for units, and who is working on it? Allowing for tanks would clearly involve extending this API, so clearly the priority should be for it to be stable and working for all the current units before worrying about new ones which stuff up everything. I would be willing to work on LUAfying the existing code, but I would need to be filled in on who has done (and is doing) what, as it's a little hard to figure out from the mantis logs.

PS: does anyone have a tool for quickly and easily viewing contents of .pck files?
[right][post="153453"]<{POST_SNAPBACK}>[/post][/right]
[/quote]

Currently the API is still in an experimental stage. It uses one unit, chameleon, and the "new units" are simply appearances and the only thing defined is sprites.
The API currently doesn't take into account armor, flying or not nor corpse sprite.
Also, units should stop being loaded as chameleon unit and should allow for fully featured units with appearances and armor types.

Nobody that I know of is working on the unit API right now.

The current API was programmed by Serge, have a look at the SVN changelog, revisions 895 - 897.

For pck editing, try Daishiva's pckview and xcview;

[url="http://www.daishiva.com/phpBB2/generic.php?page%3d%70rogLinks.shtml"]http://www.daishiva.com/phpBB2/generic.php...progLinks.shtml[/url]
(Requires Framework.Net)

Thanks for the hard work :D Edited by nachtwolf
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...