Home » MODDING HQ 1.13 » v1.13 Coding Talk » Self-Transforming Items (Pre-Project Discussion)
Re: Self-Transforming Items (Pre-Project Discussion)[message #293614] Tue, 15 November 2011 15:36 Go to previous messageGo to previous message
Headrock

 
Messages:1760
Registered:March 2006
Location: Jerusalem
 Quote:
The automatic check/add/removal is needed to prevent incorrect default inseparable attachment issues.


I am so lost with all that inseparable attachment business, I don't think I've ever seen that at work, and I'm afraid I didn't understand half of what you're saying. But I also think it's not relevant to my problem - the use of the function to handle that stuff seems very straightforward, shouldn't be any kind of problem (at least none I can see until it's actually tested in practice).

Quote:
Actually, a long time ago when I was thinking about a "transformational" capability, I aways thought of it as being a new merger type defined in the merger XML's. Instead of an entirely new feature, with new XML(s), would it be possible to leverage off of the existing merger infrastructure?


I wouldn't recommend it, for several reasons. One is that the tags would be somewhat different from merges, including several possible results (I.E. 2 or even many more items resulting from a single transformation), text for the pop-up menu if used (otherwise, tags to handle backwards/forwards transforms), etcetera. It would be much neater to handle it with a separate XML - especially because in practice this system would work nothing like merges to begin with... which is part of the problem.

Quote:
[...] a new merger type would be treated just like the existing ones


That's where the problem is, because they can't be. This is a direct result of how we cause a merge, and how we'd cause a transformation. With a merge, you take one item and click it on another item's attachment boxes, triggering a merge. There are several required parameters provided by this method which facilitate the current merger system. With a transformation, the program only knows which item is being transformed, and the results it needs to create. While this doesn't sound so different, the code itself would be VERY different indeed. And again, it also requires very different data to appear in the XMLs.

Quote:
The only problem would be that right now merger operations cannot be done on attached attachments.


Which is precisely the problem I alluded to in my previous posts. To be able to do this, the program would need to know which item the attachment is attached to, and at which position. It has to alter the data of the PARENT ITEM in order to change the attachment item, otherwise (from what I'm seeing), the attachment will not change - i.e. the program will notice a discrepancy, and fix it by reverting the item to its original form immediately.

I think there must be ways to solve this issue, but my problem is that NAS itself is written in such a complicated way that I don't understand how it works AT ALL, or how to access/work with the data. In other words, I don't know how to figure out the parent item, how to figure out which attachment slot we're working with, etcetera. It's the same reason why merges don't work for attached attachments, and only one of the people intimately familiar with NAS may be able to figure out how to do this...

Quote:
A Self-Transforming Items should be able to transform while it is attached to another item, but then there would be a need to check if the resultant item is still a valid attachment for the base gun.


If I could get to the point where the only problem remaining would be to check whether the item is still a valid attachment to its gun, that would be great - because it means I got past the problems above (figuring out what gun it is we're talking about in the first place!!). The whole problem stems from the fact that as far as I can tell, you can't look at an item and tell which other item it's attached to. This can only be done in reverse: looking at a gun and telling which attachments it has. That's a serious problem which, if unsolved, would cripple the transformation system (i.e. you'd have to remove the attachment, transform it, then put it back on, like you would with a merger).

Report message to a moderator
Sergeant Major
[Message index]
 
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Previous Topic: How to build the russian language version in VC2010 ?
Next Topic: Lower bullet damage with distance
Goto Forum:
  


Current Time: Sat Feb 15 21:08:56 GMT+2 2025

Total time taken to generate the page: 0.01332 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.1.3.
Copyright ©2001-2023 FUDforum Bulletin Board Software