UOX3.org

I hope to continue my coding shortly.

It is my undertstanding that the changes suggested to the DFN have been accepted (?)

1. Am I the only one making the data changes?

2. Am I the only one working on integrating the parser into the rest of UOX code?


Yes to both is ok, just curious if any other coordinaton is needed.

Also, please not, that the full class set uses NSPR, so I assume addition (and adoption) of that library is ok?

Everything we have discussed sounds good to me, as does the code you posted a little while back.

Were I able to, I'd be working with you to get these things implemented and continue work on what I had hoped to accomplish.

However Uni takes priority, and I've been having to work more hours, as we just recently lost an employee, so my free time has vanished, and I don't guess I'll have much of it until I finish my Bachelors.

With that said, you certainly have my blessing, punt... If you'd like I can add you on to the OpenUO project... though we might be wise to make this a seperate branch... or perhaps even entirely seperate folder from the current uox3 project repository.

giwo wrote:Everything we have discussed sounds good to me, as does the code you posted a little while back.


With that said, you certainly have my blessing, punt... If you'd like I can add you on to the OpenUO project... though we might be wise to make this a seperate branch... or perhaps even entirely seperate folder from the current uox3 project repository.

A few observations:

1. I asked on the section points, for I wanted to understand if the project felt it was valid enough to change the main branch. I can clearly keep a seperate branch regardless. So I don't see what a seperate branch here accomplishes. In fact, it discourages others to change the data formats (or build new ones in the old data format), as there becomes "two"formats. I would have preferred the discussion to have resulted in agreement with the main branch working toward the change. Clearly that isn't the case yet, so I either need to understand what technically needs to be addressed, or what other aspect is necessary to change (or is any change really allowed) for the main branch.

2. NSPR was a seperate question from the DFN changes. I can just as readily make the directory parsing of the classes not use NSPR. It was an attempt to understand if, given the spidermonkey choice,did NSPR come along with it (seems to me it would, but why I asked).



I will keep my own branch I guess, as it isn't clear that this is "really adopted" in the project yet. To also merge, there are things like Prequistes and other aspects of the OGRE project that I would like to understand why they got adopted (what purpose and is that truely what needs to be done in UOX), as it addes even more "includes everywhere" to the project. Clearly if NSPR is done correctly, the UOX_PLATFORM can go away, true?

You could just as easily throw up a new cvs/subversion repository to hold it if you don't want to taint the old uox source or want to seperate it. If you are fully porting over to NSPR I probably would be interested in helping after I finish an exam next week.

Its my opinion you should do as you wish as noone is actively developing it at the moment it seems. Can remove that UOX_PLATFORM junk and get a proper config/setup.h going too if you feel like it since you are porting over you should have to change compile options etc anyway , so go for it.

xir wrote:You could just as easily throw up a new cvs/subversion repository to hold it if you don't want to taint the old uox source or want to seperate it. If you are fully porting over to NSPR I probably would be interested in helping after I finish an exam next week.

As I stated, I am fully aware how easy it is to keep my own branch. I hoped I articulated what I was trying to accomplish before, the reasons why I wanted to change at least those aspects, and was the reasoning sufficient for the changes to be incorperated into the main branch. In particular the dfn format changes. Ability to standardize on a single data format is attractive, especially in a minimal resource situation.

Its my opinion you should do as you wish as noone is actively developing it at the moment it seems.

Yes, but that is aways an option. ideally, if others agree with the proposed changes, and the rational, then all working toward the same objective is more attractive to me.

Can remove that UOX_PLATFORM junk and get a proper config/setup.h going too if you feel like it since you are porting over you should have to change compile options etc anyway , so go for it.

Well, recall, only the NSPR stuff was related to the UOX_Platform. And one shouldn't assume I consider a config/setup.h to be "proper" as well. Given the list of platforms that gwio posted earlier, as the onese for native support, I think that is overkill as well.

Sorry for the confusion...

What we discussed and what I have read of your accomplishments is great. I think we should go ahead with it as the MAIN branch of UOX3, as official as I can make it on OpenUO.

As for my statement of making it a branch, I meant in the same way major version changes were seperate branches on the UOX3 sourceforge project, however that's not necesarry, just a thought.

If you want to put what you've worked on up on OpenUO, drop me an email with your sourceforge info, and I'll add you to the project.

Glad to see the torch is being carried

giwo wrote:Sorry for the confusion...

No worries, that is always a present issue with BBS style communication.

As for my statement of making it a branch, I meant in the same way major version changes were seperate branches on the UOX3 sourceforge project, however that's not necesarry, just a thought.

Ahh, that greatly helps clarify what was intended! May I offer, that the a slightly different approach be considered. When UOX releases something, it makes a branch. That branch is then "stable", and not touchec unless some critical patch is needed. But the head patch is always the most current development one. Otherwise, I think you will wind up in "branch hell", which I think the previous UOX CVS was approaching. The approach I described seems to work well for OpenBSD and other projects. I might also add, it only applies when a "release" of some type has been made. Has that occured?


At any rate, I have no issue contininuing on my own for a while. For to submitt changes now, would result in a broken cvs, which if releases existed, might be ok. But without them, not so sure how well it would be welcomed.