Jump to content

dose206

Members
  • Posts

    21
  • Joined

  • Last visited

Nexus Mods Profile

About dose206

dose206's Achievements

Apprentice

Apprentice (3/14)

  • First Post
  • Collaborator
  • Week One Done
  • One Month Later
  • One Year In

Recent Badges

0

Reputation

  1. We're looking at a beta tonight or tomorrow
  2. Daemonjax and I, with several others as well, are working on a distribution program to help with passing around mods. It looks like we'll likely have a workable beta build sometime this weekend. The thread is over here.
  3. Daemonjax mentioned to me that he's got an irc channel set up and that he's lonely in there..... but I'm enough a noob with irc that I don't know how to find it.
  4. No, and no... I was just describing the workflow of the modder, not what is included in the mod file. The program parses the file and creates the mod, which does not contain parts of said file. Gotcha, I thought you were describing the contents of the mod file. EDIT: Okay, an irc channel sounds good to me, I don't want to unnecessarily clutter the forums
  5. What programming language did you choose for the GUI? C#? Does dreadylein know C#? If not, this will be interesting. :D Yup, C#, although I'm not committed to it, I haven't gotten very far in yet. Don't we run into an issue with 1) by distributing game assets? Are we abandoning the index position/hash value idea? If we don't distribute the modded files themselves, then the information on which file(s) are to be modded as well as where within the file(s) and change(s) to be made will need to be in the configuration file, but we would only need that one file. Pretty sure you're right about C# XML libraries, and I agree that XML is a good format. I hadn't considered integrating hexeditor, notepad++ and ue explorer support, I was approaching it from a mod-user standpoint, but I agree that it makes more sense to view it the other way around. I don't have much experience integrating with existing software programs, do you have any suggestions on where to start looking at it? The mod manager will need its own configuration file that tracks (at least) where the XCOM installation root folder is as well as where to put/find the backups. This will theoretically be different on every user's machine, but shouldn't change through the life of use for individual users.
  6. Okay, I've gotten a very rough shell of a GUI built, and at this point it doesn't have ANY overlapping functionality with anything else, so it could easily become just a GUI used to run .bat files. Since I wanted to learn about .bat files, I also started creating a .bat file to do the job, although I'm undecided if that's the way that I want to go. Anyhow, I've successfully managed to devote nearly all of my day to this, so I'm off to study a bit before bed. I'll get back to work tomorrow afternoon, most likely. Have a nice night (or good morning) everyone! Also, if anyone is bothered by the fact that my posts don't have much substance, just tell me to shut it and post when I have some real updates. I can take it, I promise.
  7. God, I can't make up my mind. I can either work on the GUI right now, but I actually would do it in C# (I forgot how poorly Eclipse handles GUI design, VS is much easier), or I can do it command line style in Java, and worry about GUI later. I've seen the suggestion of having separate command line programs cobbled together with a GUI. What do you prefer? I don't see why not (famous last words)
  8. Dear god, man. Start studying! What class is it for? It's just Financial Accounting, and I'm pretty comfortable with the material. On another note, I think I will start with GUI, since we will eventually need it and it is what I'm most comfortable with ATM. I'm thinking I'll start with a GUI for "settings" which will be stored in a config file. Stuff like "where is your xcom installation located". Do we have a preference in terms of language? I suppose I'll start with Java, but don't imagine I'll get far enough to make changing languages too much of a hassle.
  9. Okay, Daemonjax, I've worked entirely through your gender tutorial without repacking anything. I understand now what we're talking about and what we're up against. I'll try and at least start on some code tonight and get it online (does google code support svn? I've never used them for storage). I can't promise anything because, as I mentioned earlier, I have an exam tomorrow and so far I've spent the entire day getting set up and running to mod XCom :). I should be able to get something online within a day or two. On the plus side, I ended up installing XCom on my laptop, which is far from being a gaming rig, and it runs great so far! Unexpected bonus!
  10. Daemonjax is the salty captain and I'm the greenhorn with eyes as wide as saucers, for ease of identification. EDIT: Yes, dreadylein is here too. He's the one who's not the salty captain or the wide eyed greenhorn
  11. Well, as much as I'd hate to slow everyone down by having to learn as I go... I love learning new things. Anyhow, we might be better served by getting the program working and running, and adding the GUI afterwards. In the end, I'm happy to follow your lead and happy to take directions... this is unfamiliar territory for me, after all.
  12. I love tutorialized versions.
  13. Fair enough :). I think my confusion stems from the fact that I haven't actually sat down and done any of this yet. I'm approaching it, so far, from a purely theoretical standpoint, and the doing will likely clear up most of the mist in my head. I am familiar, I have tortoise intstalled on my machine already, so I'm ready to roll there. However, I've never really worked on command line software before, I've only played with GUI stuff. However, I have full confidence that that won't be an issue. EDIT: If I'm following you correctly, modpatcher (along with some other things, like XSHAPE) is essentially modifying the structure that forces the game to read our modified files, while what we've been talking about here is how to automate and distribute the actual modified files (in such a way to avoid copyright issues, etc.) EDIT2: Nope, I think I got it now. I'm actually going through and doing and that makes a huge difference. Modpatcher is used if you want to fiddle around in the .inis. We're not doing that. After following along with your gender tutorial (almost finished with it) I can see that we're not messing with .inis at all. Gosh, I should have just jumped in with both feet in the first place. I'm a little slow some days, you'll have to forgive me ;)
  14. This is off topic, but after spending a few hours combing through some of the more prominent threads I have a question. Does anybody recommend a particular hex editor? I've never used one before and would prefer to start off with a decent one rather than jump my way through a few crappy ones until I figure out which features I like(need). Thanks in advance.
  15. We'd have to use both methods, if we want to support mods on top of mods. If we were only looking at the hash values, and they had been modified previously, our program would have no way of knowing where to patch in the new code. I do love the idea of using hash values, either around the area to be modded, or as the "expected value" that you mentioned previously, but we would need to have the byte's offset as well. I was thinking it could be even more simple. Our modder creates a single file that contains, like you mentioned previously, the name of the file to be modified (filename.upk.original, and it could optionally check for filename.upk.modified, if the user knows this file has been modified previously). It would also contain the byte offset and perhaps the hash values, and then of course the new code to patch in. That's it, at least starting out. All our modder has to do to distribute his mod is send this one file out, and all our user has to do is run this file through our program. There could be some config settings for the user, such as where all the unmodified upks are, as well as the modified ones, but it seems to me that it doesn't have to be more complicated than that. Unless, of course, we want to support more heavily the mod makers as well. I guess it depends on exactly what the scope of this part of the program needs to be. EDIT: After reading your suggestion again, it sounds like we're suggesting essentially the same thing EDIT2: I reread through ALL the relevant threads in an effort to make sure I have all the proper software and understand the process properly. I haven't actually tried anything yet so pardon my ignorance, but aren't we talking about doing (essentially) what dreadylein's Modpatcher is already doing? If not, then I'm having trouble understanding what that program does.
×
×
  • Create New...