Home » MODDING HQ 1.13 » v1.13 General Development Talk » "1.13" Mod - Main Thread
|
Re: "1.13" Mod - Main Thread[message #10689]
|
Tue, 06 September 2005 04:18
|
|
Kaiden |
|
Messages:504
Registered:September 2003 |
|
|
Snap, I saw your other thread asking for help, and unfortunately, off the top of my head, I can't help you, it's been quite a while since I loaded up the original JA2 source code, was a different comp, so I'm having to re-install everything. Soon as I get it all loaded up, I'll post you some step by steps ok?
Khor, Didn't someone on here somewhere mention that the 1.07 patch was on the original CD? If so which one? the Play disc or Install Disc? Either way, if it wouldn't be too much of a problem and you e-mailed it to me, that would solve the issue either way, then I would be able to load up any version of Ja2. (Burning all this extra crap on a CD this time so I don't have to worry about trying to find it all online next time i have to reload) But I'm not bitter!
EDIT: Yeah it might help if you knew how to e-mail me, I recently e-mailed you regarding the desktop utilities. acyf88.
EDIT2: Well I can't seem to find my .NET Cd's. lost in the last move would be my guess, I'll have to get mad about it later, for right now, I'm gonna install VC6 and see if I can get it to compile and build there. I don't see why not, aside from some minor syntax issues which are probably not an issue in this particular code, I doubt there are too many .Net functions being used (except for maybe some of the xml reading MM?)
Report message to a moderator
|
|
|
|
|
Re: "1.13" Mod - Main Thread[message #10691]
|
Tue, 06 September 2005 07:18
|
|
Madd_Mugsy |
|
Messages:634
Registered:July 2005 Location: Canada |
|
|
Sorry for the delay folks. I've been busy with RL and with working on the mod.
After some playtesting, I've decided to scrap integrated grenade launchers since they're just using the same firing stats as the guns. Instead, just create a new attachment, give it the inseparable attribute, and use the new tag I just added, DefaultAttachment, to specify the GL attachment.
Plus by doing it this way, I'm able to put in another feature I've just figured out how to do...
The tileset redraw bug is still there. I was hoping that some of the UB blitting code would fix it, but no luck.
I've figured out what causes the invisible hicks/enemies bug, but I'm still not sure why it happens.
Would someone be able to please do up some nice 9mm and 5.56mm feed clip kit pics for me? Mine look like crap.
Kaiden:
Any help you can provide would be much appreciated. I'm a VB/VB.NET guy and I'm kind of learning C++ as I go here. I'm pretty much hacking at this point, and I know I'm writing uglier code than I would need to in VB, but I'm just not familiar enough with the language to do any better. I could really use some help with tracking down some of the bugs.
You can enable logging to Debug.txt by enabling the SGP_DEBUG define in builddefines.h and then using the DebugMsg function to write to the file.
Cheers and TIA!
Report message to a moderator
|
|
|
|
|
|
|
|
Re: "1.13" Mod - Main Thread[message #10696]
|
Tue, 06 September 2005 14:17
|
|
Kaiden |
|
Messages:504
Registered:September 2003 |
|
|
DecideAction
CheckIfTossPossible
calcmaxtossrange
CheckIfSniperShotPossible
CheckIfSniperShotPossible: found a gun item # 338
CheckIfSniperShotPossible: weapon type 1
CheckIfSniperShotPossible: checking for scope
decideactionred: sniper shot not possible
decideactionred: weapon in slot #5
decideactionred: men in sector 1, ubspotters called by 0, nobody 156
decideactionred: crouch and rest if running out of breath
decideactionred: calculate morale
decideactionred: radio red alert?
decideactionred: main red ai
decideactionred: check to continue flanking
decideactionred: checking to seek
decideactionred: couldn't seek
decideactionred: checking to watch
decideactionred: couldn't watch
decideactionred: checking to help
decideactionred: couldn't help
decideactionred: checking to hide
decideactionred: couldn't hide
decideactionred: nothing to do!
decideactionred: look around towards opponent
Music EndCallback 513 5
Music EndCallback completed
Ok here's what I found, it seems to stop at "look around towards opponent" and then crashes, I get no further debug messages. The fact the Music EndCallback completed is called, indicates to me (and I'm no authority on the subject having not looked at the source code in almost a year) that it crashed "gracefully" meaning that the current function ended and returned, causing the calling procedure or function to also end abruptly, all the way out until the game itself was exited as if someone hit the "quit" button.
Otherwise, there should be alot more messages between :
decideactionred: look around towards opponent
and :
Music EndCallback 513 5
Music EndCallback completed
So just from reading this and skimming through decideaction.cpp, Something is missing in the end if an enemy makes it all the way through the RED actions loop without finding anything to do.
The previous decide action messages were these:
DecideAction
CheckIfTossPossible
calcmaxtossrange
CheckIfSniperShotPossible
CheckIfSniperShotPossible: found a gun item # 7
CheckIfSniperShotPossible: weapon type 1
CheckIfSniperShotPossible: checking for scope
decideactionred: sniper shot not possible
decideactionred: weapon in slot #5
decideactionred: men in sector 2, ubspotters called by 0, nobody 156
decideactionred: crouch and rest if running out of breath
decideactionred: calculate morale
decideactionred: radio red alert?
decideactionred: main red ai
decideactionred: check to continue flanking
decideactionred: continue flanking
FindFlankingSpot: orig loc = 8229, loc to flank = 4869
FindFlankingSpot: direction to loc = 0, dir to flank = 2
FindFlankingSpot: return grid no 7752
DecideAction done
NPCDoesAct
NPCDoesAct done
Soldier 21: Get new path
Anyway I searched up, and found a few more decide action sets, this one seems to be a problem to me at this point, but I could be wrong:
DecideAction
CheckIfTossPossible
calcmaxtossrange
CheckIfSniperShotPossible
CheckIfSniperShotPossible: found a gun item # 7
CheckIfSniperShotPossible: weapon type 1
CheckIfSniperShotPossible: checking for scope
decideactionred: sniper shot not possible
decideactionred: weapon in slot #5
decideactionred: men in sector 2, ubspotters called by 0, nobody 156
decideactionred: crouch and rest if running out of breath
decideactionred: calculate morale
decideactionred: radio red alert?
decideactionred: checking to radio red alert
decideactionred: main red ai
decideactionred: check to continue flanking
decideactionred: checking to seek
decideactionred: couldn't seek
decideactionred: checking to watch
decideactionred: couldn't watch
decideactionred: checking to help
decideactionred: couldn't help
decideactionred: checking to hide
Then about 500 of these:
GunRange: rng=200
GunRange: base rng=200
GunRange: rng=200
GunRange: base rng=200
GunRange: rng=200
GunRange: base rng=200
GunRange: rng=200
GunRange: base rng=200
GunRange: rng=200
GunRange: base rng=200
GunRange: rng=200
GunRange: base rng=200
Then finally gets down to:
DecideAction done
NPCDoesAct
NPCDoesAct done
Soldier 21: Get new path
Deduct Points (21 at 9034) 2 10
And 2 Decideaction's before that whole set, was this one:
DecideAction
CheckIfTossPossible
calcmaxtossrange
CheckIfSniperShotPossible
CheckIfSniperShotPossible: found a gun item # 338
CheckIfSniperShotPossible: weapon type 1
CheckIfSniperShotPossible: checking for scope
decideactionred: sniper shot not possible
decideactionred: weapon in slot #5
decideactionred: men in sector 2, ubspotters called by 0, nobody 156
decideactionred: crouch and rest if running out of breath
decideactionred: calculate morale
decideactionred: radio red alert?
decideactionred: checking to radio red alert
decideactionred: main red ai
decideactionred: check to continue flanking
decideactionred: checking to seek
decideactionred: seek opponent
decideactionred: couldn't seek
decideactionred: checking to watch
decideactionred: couldn't watch
decideactionred: checking to help
decideactionred: couldn't help
decideactionred: checking to hide
decideactionred: couldn't hide
decideactionred: nothing to do!
decideactionred: look around towards opponent
DecideAction done
NPC has no action assigned
Which I beleive is how the last one SHOULD have ended. I think that maybe, there was a problem finding a merc to look towards. But... It's late and I'll take another look at it tommorrow evening when I get home from work, right now I'm tired and gotta go to bed.
Mugsy, if you have time/want to look through it, if it's useful info, I was playing with the default settings which are Experienced, Good, and Everything (I beleive).
I had Magic and Shadow on one-day tickets, and all of the enemies had pistols of one kind or another. And playing in this fashion, I've crashed the game 3 times in Sector A9.
EDIT: it's going to take me some time to get back up to speed on the source, especially now that it's heavily modified. Until then I'll do the best I can at spotting bugs in the code, you may have to "remind" me which source file I'm looking for in some cases though, this one was easy to find because of the debug log. Anyway like I said, I'll look at the code again tommorrow and see if I can spot what's crashing.
Report message to a moderator
|
|
|
|
|
|
Re: "1.13" Mod - Main Thread[message #10699]
|
Tue, 06 September 2005 19:02
|
|
Snap |
|
Messages:286
Registered:September 2000 Location: USA (by way of the Old Wo... |
|
|
@John: OK, you can download my custom sets here:
http://www.geocities.com/tacpans/tilesets/
(Hope this will work without the index.) The file is snap-sets.zip. See the text file inside the archive. Console STI tools are also on the site in case you might need them. The custom sets include JSD files that "should" work, but they are not 100% tested.
Oh and in case you are wondering why you can't get JA2 to accept tilesets with higher numbers, that's because the limit is hardcoded. To change, add elements to the enum in TileEngine\World Tileset Enums.h. It's best to check the UB code to see how it's done there, in case there are some non-obvious tricks involved.
You should also be aware that even if the tileset limit is increased, simply adding UB tilesets to JA2 won't work. That's because in JA2 the very first tileset acts as a default resource for all subsequent tilesets. IN UB tileset 50 is the default for all tilesets above 50. So, while tileset 50 will still work in JA2 (since it is completely filled), other UB tilsets will be broken.
Once the tileset limit is successfully increased, I can recompile UB tilesets to work in JA2. As for other modifications, I would advise to make them strictly backwards-compatible, at least as part of this project. That is, old maps should still work and, ideally, look the same even with changed tilesets. One way to accomplish such modifications is to add extra objects at the end of STIs that are not filled to capacity - there are a few such examples in my collection. Another way is to replace a duplicate subset in a tileset. However, this can in principle break some maps.
@Kaiden: Thanks for offering help. I'll probably have another go with the source before the end of week.
Report message to a moderator
|
Master Sergeant
|
|
|
|
Re: "1.13" Mod - Main Thread[message #10701]
|
Tue, 06 September 2005 22:37
|
|
the scorpion |
|
Messages:1834
Registered:September 2004 Location: CH |
|
|
yes
adding new items to the jsd files and to the according .sti`s is a safe way of adding new items to an existing tileset (like it was done it ja2 vengeance for instance)
this won`t change anything in eyisting map files
however, the wish (from my side at least) is to raise tileset number and add new tilesets. because the first method can easily be done using a jsd editor and doesn`t require any code changes
Report message to a moderator
|
Sergeant Major
|
|
|
|
|
|
|
|
Re: "1.13" Mod - Main Thread[message #10707]
|
Wed, 07 September 2005 04:08
|
|
the scorpion |
|
Messages:1834
Registered:September 2004 Location: CH |
|
|
just some points: the betaeditor for ja2 allows creating ja2 format maps, placing NPC/ RPC, locks, basicly all you need as a modmaker, except fro the new items exclusive to the 1.13 mod
the point is, the UBeditor is pretty useless compared to the beateditor. if it is possible to bring in the new items into a editor that has the features of the betaeditor that would be absolutely great. just note that the UB Editor is not the tool that is currently in use for creating maps for ja2
Report message to a moderator
|
Sergeant Major
|
|
|
|
|
|
|
Re: "1.13" Mod - Main Thread[message #10712]
|
Wed, 07 September 2005 06:57
|
|
Kaiden |
|
Messages:504
Registered:September 2003 |
|
|
For the new grenade launchers (full sized non-attachment kind) my guess is he's using grenades like normal ammo is used.
For the attachment kind, then all I can guess is that either yes, you need to load a few grenades as attachments, or he's managed to figure out a way to pull grenade ammo right out of your pack for launchers.
Till he releases the next version, we'll never know
EDIT: Also following MM's example, I've created two new threads in this forum, for bugs and non-item related feature requests. It's going to get difficult trying to read through this whole thread.
EDIT2: New attachment slots would require some graphics editing, as well as alot of code. We're gonna have to try to work around it if we need it.
One option, would be attaching attachments to attachments. Like for instance, loading grenades into a Talon as Attachments, and then loading the Talon as an attachment to the gun (may be what he's already done, and if so, it can be applied to other items).
Report message to a moderator
|
|
|
|
|
Re: "1.13" Mod - Main Thread[message #10714]
|
Wed, 07 September 2005 07:42
|
|
Madd_Mugsy |
|
Messages:634
Registered:July 2005 Location: Canada |
|
|
Kaiden,
Thanks for adding those threads. This one's getting pretty long
For the grenade launchers, I went outside the box...
We can't put attachments on attachments, or alter the OBJECTTYPE structure in any significant way. Doing so screws up the map loading process and the screen will turn red in-game, even though it compiles. So that didn't work.
I also wanted both attached and standalone GLs to continue to use the same launching code. So ammo for one and attachments for the other was no good.
What I ended up doing was a fairly simple hack to make multiple shots possible (the burst code was slightly more involved): I made it so that GLs look at the MagSize weapon attribute: if it's > 1 then any attached launchable can be fired up to MagSize number of times.
Since I can't change the OBJECTTYPE structure, I simply reduce the status of the launchable until it it is used up and removed. The launchable should not have the damageable or repairable flags set (just like the ammo items), so you can't just keep refilling your GL ammo with a toolkit.
This means that multi-shot GLs need their own special ammo that can't be used by single-shot GLs - not really a big deal, considering how many item slots we've got.
You also won't be able to top-off your GL ammo like regular ammo. I'll make it so that GL ammo can be combined like med kits, etc.
Finally, the OICW has an "integrated" GL. It's an attachment marked with the inseparable flag.
I created a DefaultAttachment flag which enables you to specify an attachment that is always attached to a new instance of an item. I set this on the OICW to be the OICW-GL.
Since it's inseparable, it doesn't come off, and since it's the default attachment, it's always there when you find/buy a new OICW. (It's not sold separately ) The OICW loses an attachment slot, but it's already got a built-in laser scope and reflex scope, so it's in pretty good shape anyway.
Report message to a moderator
|
|
|
|
|
|
|
|
|
|
|
Re: "1.13" Mod - Main Thread[message #10722]
|
Wed, 07 September 2005 15:38
|
|
Madd_Mugsy |
|
Messages:634
Registered:July 2005 Location: Canada |
|
|
GrindedStone,
That's exactly how it works!
Snap,
The grenades are attached to the launcher just like regular grenades, so, no, it wouldn't work with guns right off the bat like that. (it'd need some work)
I haven't enabled autofire for GLs, just burst fire. This is because of two reasons: 1) balance and 2) it's more work than I care to do right now.
The MGL only fires 3 grenades at a time. Enough to kill a few enemies grouped together in one spot, but not enough to really dominate the battlefield, especially with only six shots per cylinder and cylinders only available at Bobby Ray's.
The OICW works similarly, but only fires 2 shot bursts, and it's 20mm grenades don't do as much damage. They're also only available through good ol' BR.
Report message to a moderator
|
|
|
|
|
|
Re: "1.13" Mod - Main Thread[message #10725]
|
Wed, 07 September 2005 23:50
|
|
Kaiden |
|
Messages:504
Registered:September 2003 |
|
|
I have a concern about the whole project, actually it's more of a feeling of disappointment in the secretive nature of some modders on this forum, specifically members of the "Mod Squad". Now I do have to respect their skills, but it seems to me that they have a sort of elitist nature about them. From what Bearpit posted last month about their project, they've only got 4 people working on. And not sure if Batman is one of them, although, he does seem interested in this project that Mugsy has started, so maybe he is, maybe he isn't.
I just kind of expected that this would all turn into an "open source" type of community project with those that had the skills leading, and those that didn't learning and helping. And after watching the WhiteHat project for over a year and seeing nothing come about, I can understand why several groups intent on doing SOMETHING split off and did what they did. I mean personally I didn't share my project information with anyone because no one was interested, hell, even the deadly games fans didn't seem to thrilled. I can understand that, you don't know what to expect until it's finished, and then you can appreciate it, but getting excited over yet another "false promise" to provide them with the style of play they are used to, in a more advanced game engine is not going to happen with that crowd.
But what we're going to end up with is about 5 completely different styles of incompatible games and tools that don't work across versions. For instance, we could really use the source for the Beta Editor, but that belongs to another "team". I'm sure Bearpit would be interested in some of our ideas, and they may or may not incorporate them, but it sure would be nice to meld the two projects into one, then we'd have at minimum 10 people working on one project, instead of 4 people over there and 6 over here.
Report message to a moderator
|
|
|
|
Re: "1.13" Mod - Main Thread[message #10726]
|
Thu, 08 September 2005 00:34
|
|
grindedstone |
|
Messages:88
Registered:August 2004 |
|
|
Kaiden, i do agree that things need to be more unified, but we also need a decent version to back things off. Mugsy has removed the item limit, from now on all mods should have have no item limit (example)
sure this may take time, but if this 1.13 is done right, it will be a strong base for further mods by having reduced the difficulty/removed barriers.
I am not a programmer and am just a spectator in this project, but i think the good programmers we have such as you should all work in cleaning out your own selection of code that (if possiable) is not affected by other code, so we can have 10 poeple over 10 places for now while we establish a base, but if this 1.13 is a great base making future mods easier, everyone should work on laying the foundations, then installing the plumming and electricity (editors and tools) then the frames, wells and paint can be the mod makers choice, but it is vital to have a strong base.
Report message to a moderator
|
Corporal 1st Class
|
|
|
Re: "1.13" Mod - Main Thread[message #10727]
|
Thu, 08 September 2005 00:59
|
|
Kaiden |
|
Messages:504
Registered:September 2003 |
|
|
I was talking more about the other modders on this forum, What's left of the "Mod Squad" is currently working on a project, and other than Bearspit, I don't know who else is involved with that, but they are heavily modifying the source code from what I read in the post. In addition, I'm sure there are at least another group or 3 that are doing the same thing. If we all just worked together, we'd get everything done in twice the time, but the end result would be much better I think. I beleive Mugsy is looking at sharing his code, he just doesn't have version control right now, so only one person can modify the code without causing issues. And we can't all just work on one peice of the code, because beleive me, if you want to change something, chances are, you're change is going to effect any number of files, and depending on the type of change your making, it could affect almost all of them. No the problem I was referring to, is the fact that there are at least 2 modding projects going on right now, and probably more that we don't even know about yet, and since the source code was released, all of those projects will be modifying it at least a little. We'll end up with 5 different 1.12+ versions of the executable, different methods of externalization of data, different map formats etc... And Moding will not only become a pain for the modders, it will become a pain for the end user.
Essentially, we'll end up with the whole Betamax vs. VHS debacle, and in the end, the majority of modders will chose one or the other or the other to mod, so they don't have to learn how to mod all of them, the end user thus has the disadvantage of losing one great feature over another, because he wants to play ModX, but with VersionY and ModX wasn't made for VersionY, it was made for VersionZ which is incompatible and lacking a Feature that he/she likes.
Report message to a moderator
|
|
|
|
Pages (19): [ 14 ] |
|
Goto Forum:
Current Time: Thu Apr 18 00:36:09 GMT+3 2024
Total time taken to generate the page: 0.03597 seconds
|