Zandronum Chat on our Discord Server Get the latest version: 3.1
Source Code
My View | View Issues | Change Log | Roadmap | Zandronum Issue Support Ranking | Rules | My Account
  

View Issue Details [ Jump to Notes ] [ Issue History ] [ Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0002777Zandronum[All Projects] Suggestionpublic2016-07-12 01:062016-07-26 17:26
ReporterStrikerMan780 
Assigned ToTorr Samaho 
PrioritynormalSeveritymajorReproducibilityN/A
StatusassignedResolutionopen 
PlatformMicrosoftOSWindowsOS VersionXP/Vista/7
Product Version3.0-beta 
Target VersionFixed in Version 
Summary0002777: SurfaceSkin modeldef property for MD3s
DescriptionRight now, to do per-surface/group texturing in Zan/GZDoom, you need to set the path to the texture in the MD3 file. This can be extremely cumbersome if you have multiple skins for different purposes, because it means you have to copy the model to a new file, edit the texture paths, and so on. If your models have a lot of texture frames, or you have many different variants, and the models are detailed/lots of animation frames... this boats filesize by a metric fuck-ton.

If one could change/set surface textures in ModelDef, it would solve this problem. You could have a base model, and set the skins however you desire from there.

Right now, if this were added, I could shave 70 MEGABYTES of data off of SMMP. This would be a godsend to me and anyone else who wants to download the mod, and a godsend to anyone who's doing model-heavy work in Zandronum.
Attached Files

- Relationships

-  Notes
User avatar (0015284)
StrikerMan780 (reporter)
2016-07-12 01:10
edited on: 2016-07-12 01:14

 Ugh, wish the poster could be allowed to edit his own ticket... this limitation is fucking horseshit. Missed an important detail.

Anyhow, the syntax would be as follows:

Model BFG10K
{
    Path "Models\HUD\BFG10K"
    Model 0 "BFG10K.md3"
    SurfaceSkin "Gun" "Models\HUD\BFG10K.png"
    SurfaceSkin "PlasmaTube" "Textures\PLASBLUE.png"
    Scale -5.0 3.5 5.0
    ZOffset -6
}

I can't imagine this would be too hard to implement considering per-surface texturing is already in, just not available to MODELDEF. (Which it should have been from the beginning.)
User avatar (0015285)
StrikerMan780 (reporter)
2016-07-12 01:19

 This would mean I could avoid crap like this:'http://puu.sh/pYy5J/0d823b22de.png [^]'
Argh!
User avatar (0015288)
StrikerMan780 (reporter)
2016-07-12 06:54
edited on: 2016-07-15 03:38

 Implemented this myself.

Here's the pull request:'https://bitbucket.org/Torr_Samaho/zandronum/pull-requests/120/surfaceskin-for-modeldef-allows-modders-to/diff [^]'

A small change was made to the proposed syntax.

This is an example of it in action:

Model BFG10K
{
    Path "Models\HUD\BFG10K"
    Model 0 "BFG10K.md3"
    SurfaceSkin 0 0 "Models\HUD\BFG10K\BFG10k.png"
    SurfaceSkin 0 1 "Textures\PLASBLUE.png"
    Scale -5.0 3.5 5.0
    ZOffset -6

    FrameIndex BG2G A 0 0
    FrameIndex BG2G B 0 1
    FrameIndex BG2G C 0 2
    FrameIndex BG2G D 0 3
    FrameIndex BG2G E 0 4
    FrameIndex BG2G F 0 5
    FrameIndex BG2G G 0 6
    FrameIndex BG2G H 0 7
    FrameIndex BG2G I 0 8
    FrameIndex BG2G J 0 9
    FrameIndex BG2G K 0 10
    FrameIndex BG2G L 0 11
    FrameIndex BG2G M 0 12
    FrameIndex BG2G N 0 13
    FrameIndex BG2G O 0 14
}

Here's a screenshot of it in action, after changing plasblue.png to another texture.'http://puu.sh/pYLMH/12d959b893.png [^]'
User avatar (0015291)
Edward-san (developer)
2016-07-12 13:02

 What about submitting this to GZDoom first?
User avatar (0015292)
StrikerMan780 (reporter)
2016-07-12 13:33
edited on: 2016-07-12 16:57

 I explained why I didn't on the pull request. Too many differences in GZDoom and Zandronum 3.0, among other reasons. I'll need to rewrite it when the time comes.
User avatar (0015294)
StrikerMan780 (reporter)
2016-07-12 17:22
edited on: 2016-07-12 17:22

 Made some final changes, 'tis ready to go.
User avatar (0015295)
Torr Samaho (administrator)
2016-07-12 18:32

 First, nice to see that you working on improving the model code!

I didn't had a chance to take a closer look at your implementation, before I do so, I need to make a general remark. This is the first pull request where this is relevant, that's why I didn't point this out anywhere yet.

I have to keep the zdoom-sync branch in sync with both both GZDoom and our main branch aka 3.0. As a consequence, everything that goes into 3.0 must be merged with the zdoom-sync branch immediately. For things that merge easily I just do this myself silently. This pull request here though likely falls into the category where merging it with the zdoom-sync branch is not that straightforward. This means before I can consider pulling this into 3.0, you would have to merge your changes with the zdoom-sync branch. Since that essentially means that you have to merge your changes with GZDoom's master branch, I suggest a different approach:

Merge you changes into GZDoom's master branch and make a pull request there. If that is accepted I will merge it into the zdoom-sync branch. If you then make a pull request that backports your additions to 3.0 I will pull that one. This way you don't have to wait ages for 4.0 and we get zero additional delta in the zdoom-sync branch.
User avatar (0015299)
StrikerMan780 (reporter)
2016-07-12 20:22
edited on: 2016-07-12 20:30

 Not sure how that works, but I'll re-do my implementation in GZDoom.

If I implement this feature into GZDoom, what exactly would I do from there? Would I cancel this pull request, and make a new fork, do it in GZDoom, have it pulled into Zandronum Sync? Then just commit and pull request what I've already done for 3.0 after that?
User avatar (0015300)
StrikerMan780 (reporter)
2016-07-12 21:39

 Working on a new, less intrusive implementation that should be vastly easier to backport.
User avatar (0015304)
Torr Samaho (administrator)
2016-07-13 18:09
Quote from StrikerMan780

If I implement this feature into GZDoom, what exactly would I do from there? Would I cancel this pull request, and make a new fork, do it in GZDoom, have it pulled into Zandronum Sync?

One step is missing. After you implement it in GZDoom, submit a pull request to the GZDoom repo and have them pull it. I'll then pull and merge it from the official GZDoom repo into our zdoom-sync repo.
Quote from StrikerMan780

Then just commit and pull request what I've already done for 3.0 after that?

If your code doesn't change on its way into the official GZDoom repo (apart from the changes that are unavoidable for the merging), then yes. If your code changes on the way, the changes should also be in your backport for 3.0.
User avatar (0015309)
Dark-Assassin (administrator)
2016-07-15 01:27

 SurfaceSkin should be:
    SurfaceSkin [ModelID] [SkinID] "SkinFile"
And not:
    SurfaceSkin [SkinID] "SkinFile"

Otherwise use of multiple models on a single actor could break it.


On a side note, could the model and skin limit be removed?
User avatar (0015310)
StrikerMan780 (reporter)
2016-07-15 03:37
edited on: 2016-07-16 04:48

 If you read the Push request, you'd have know that's already been taken care of 3 days ago.

As for the model/skin limit. It can only be raised, not removed.
User avatar (0015325)
StrikerMan780 (reporter)
2016-07-16 04:48

 'https://github.com/coelckers/gzdoom/pull/58 [^]'

Push request submitted to GZDoom. I hope it makes it in.
User avatar (0015326)
StrikerMan780 (reporter)
2016-07-16 07:40

 It was added. See:'https://github.com/coelckers/gzdoom/commit/1ef8057fa7df0131f51416b39b0b9f4c8548f980 [^]'

Just need to update the zandronum-zdoom-sync branch, and then I'll work on the backport.
User avatar (0015328)
Torr Samaho (administrator)
2016-07-16 15:21

 I just synced our zdoom-sync branch with GZDoom and 3.0, so you can start with the backport. The fact that you spread your change over 4 commits makes things a little more cumbersome, but that can't be changed anymore now.

To backport your change, please use "hg graft" or "hg transplant" to transfer your four commits from the zdoom-sync branch to 3.0.
User avatar (0015329)
StrikerMan780 (reporter)
2016-07-16 16:34
edited on: 2016-07-16 17:59

 How exactly would I do this? According to what I've read, you cannot graft from another repository.

EDIT: Yeah, I'm going to need some instruction here. This is confusing as all fuck. This would be much easier of Zandronum-ZDoom-Sync was a branch and not a whole other repository.
User avatar (0015330)
Torr Samaho (administrator)
2016-07-16 18:00

 Yes, you cannot graft to another repository, but that doesn't matter in our case. Just make a local clone of the zdoom-sync repo, graft the four commits one after another to the 3.0 branch (IMO the most convenient way to do this is with TortoiseHg, see here for instance). Then you can push the four grafted commits from your local repo to your Zandronum fork on bitbucket. Since the graft info is saved in the changeset meta data, it will survive the pushing, and will help me once I sync 3.0 with the zdoom sync branch again.
User avatar (0015331)
StrikerMan780 (reporter)
2016-07-16 18:08
edited on: 2016-07-16 18:10

 zandronum-zdoom-sync does not have a 3.0 branch. There's nothing for me to graft to.

'http://puu.sh/q3P4d/43121710a6.png [^]'
User avatar (0015332)
Torr Samaho (administrator)
2016-07-16 18:13

 It's not a named branch. Simply update your working copy of your zdoom sync repo clone to the last commit of 3.0, currently it is the one with hash 89198ae0737fcb8baefa5375b40b26c61873d148.
User avatar (0015333)
StrikerMan780 (reporter)
2016-07-16 18:17

 So, I would fork the zdoom sync repo first?
User avatar (0015334)
Torr Samaho (administrator)
2016-07-16 18:22

 You don't need a fork of the zdoom sync repo, a local clone is sufficient. From there you can push it into your zandronum fork. If you prefer to work with a zdoom sync repo fork that is fine with me as well though. As long as they are grafted to 89198ae0737fcb8baefa5375b40b26c61873d148, it makes no difference to me whether I pull the four grafted commits from a zandronum fork or a zdoom sync fork.
User avatar (0015335)
StrikerMan780 (reporter)
2016-07-16 18:36
edited on: 2016-07-16 18:55

 None of this makes any sense to me. I've never worked with Mercurial before until recently.

If I try to clone the zandronum-zdoom-sync repo, and graft my changes to 89198ae0737fcb8baefa5375b40b26c61873d148, it gets merge conflicts out the anus and since 89198ae0737fcb8baefa5375b40b26c61873d148 is merged with 4.0, there it already includes all of the merged changes with GZDoom 2.0... which there are some lines mutually incompatible with how 1.8.6 / Zandronum 3.0 does things. Texture management is totally different, etc. They are just single-line differences, but with the merge conflicts, I can't tell what goes where. It's a scrambled mess.

This is just an utter clusterfuck. I can backport it manually no issue however, in a 3.0 fork.

Also, push into my Zandronum fork? Which one? How? What?

I need a step-by-step from square one on how to do this from TortoiseHG, click-by-click, window-by-window... otherwise this is far too cryptic.

I'm really thinking Mercurial was a bad choice... it's way of handling branching, merging, etc is utter madness in comparison to GIT.
User avatar (0015336)
Torr Samaho (administrator)
2016-07-16 18:55

 Sorry, I assumed that you are familiar with Mercurial since you already forked my repo and created pull requests before. Unfortunately, I have no time to write a grafting tutorial, but there should be documentation for that. I can try to look for a tutorial eventually, but that may take some time.

Quote from StrikerMan780
which is mutually incompatible with how 1.8.6 / Zandronum 3.0 does it. Texture management is totally different, etc.

Does this mean that your change in 3.0 and your change in GZDoom are completely different and use totally different mechanisms? Or do you just have to do some translation since things moved to different positions, function names and data structures changed, etc.?
User avatar (0015337)
StrikerMan780 (reporter)
2016-07-16 18:56
edited on: 2016-07-16 19:09

 My original pull request and the one in GZDoom are drastically different. I redid everything from scratch to make it less intrusive (no modifying function parameters, leaving existing lines alone, fewer files modified, easier to backport). I can make a new 3.0 fork and backport these changes manually quite easily without changing many (if any) existing lines.

For example, in 3.0, I'd need to change smf.surfaceskinIDs[index][surface] = FNullTextureID(); to smf.surfaceskinIDs[index][surface] = NULL;

if (!smf.surfaceskinIDs[index][surface].isValid()) to if (smf.surfaceskinIDs[index][surface] == NULL)

etc...
User avatar (0015338)
Torr Samaho (administrator)
2016-07-16 18:59

 Let me clarify, I didn't mean your old pull request, but your planned 3.0 change, i.e. how you would implement it in 3.0 now given that you should approximate what you did in GZDoom as closely as possible.
User avatar (0015339)
StrikerMan780 (reporter)
2016-07-16 19:00
edited on: 2016-07-16 19:12

 Edited my last note. There's nothing different between *my* changes in GZDoom/Zan 4.0 than what I'd do in 3.0, save for a couple lines.

My merge conflicts were because there's such a drastic difference between Zandronum 3.0's gl_models.cpp and 4.0's gl_models.cpp. (Same with gl_models_md3.cpp, gl_models.h, and gl_scene.cpp)

I can create a new 3.0 fork, import my changes there (matching 4.0 as close as possible) and then make a push request, will that work?
User avatar (0015340)
Torr Samaho (administrator)
2016-07-16 19:12
edited on: 2016-07-16 19:14

 That's what I hoped. Then grafting is exactly the right thing to do. It will assist you in recreating your changes in 3.0 and keep note internally that this is a backport, not new code. The latter is why I ask you to graft (or transplant, but that is a bit more tricky) the code instead of manually redoing the changes in 3.0. Unfortunately, we'll have to continue this discussion another time.

EDIT: Since you edited your post while I was writing mine, my answer applies to your original version:
Quote from StrikerMan780
Edited my last note.
User avatar (0015341)
StrikerMan780 (reporter)
2016-07-16 19:31
edited on: 2016-07-16 20:07

 I think I may have it figured out. Is this right?'http://puu.sh/q3T5i/d27c6859f7.png [^]'

If so, and I didn't create a fork of the sync branch, how do I get it from there to Zandronum 3.0?
User avatar (0015342)
Torr Samaho (administrator)
2016-07-16 20:08

 Yes, that looks good! You now need a fork of either Zandronum or the zdoom-sync repo you can push your changes to.
User avatar (0015343)
StrikerMan780 (reporter)
2016-07-16 20:12

 And by push, copy the resulting files? Or is there a way to "push" between repositories?
User avatar (0015344)
Torr Samaho (administrator)
2016-07-16 21:03
edited on: 2016-07-16 21:12

 There is a "push" command to transfer commits from one repository to another. It's very likely that you used "hg push" while creating your old pull request for 3.0, so I assumed you know the term. Possibly, the GUI you used hid the name of the command from you.
User avatar (0015345)
StrikerMan780 (reporter)
2016-07-16 21:06
edited on: 2016-07-16 21:08

 In TortoiseHG, or Bitbucket?

This is what I try to get if I try to push to a URL of a 3.0 fork via TortoiseHG:'http://puu.sh/q3Ykb/348a25c04d.png [^]'
User avatar (0015346)
Torr Samaho (administrator)
2016-07-16 21:16

 The "push" button in TortoiseHg will push everything you have locally to the target URL, you only need to push your four new commits.
User avatar (0015347)
StrikerMan780 (reporter)
2016-07-16 21:18
edited on: 2016-07-16 23:25

 See the image? Says it'll end up creating a new head, and errors out.

I did the following:

cloned zandronum-zdoom-sync.

Updated to the revision you told me to graft to.

Grafted the 4 commits of mine to local.

Made a fork of the main zandronum (3.0) repository.

Tried to push to the fork of 3.0. Failed.
User avatar (0015348)
Edward-san (developer)
2016-07-17 00:03
edited on: 2016-07-17 00:04

 You need to set the 'force pushing' this way: in the GUI, open the Syncronize panel from the toolbar (the one with the circling arrows), then click on the 'Options' button (between 'Post Pull: None' and 'Target') and check 'Force push or pull (override safety checks,--force)'. Save it and try again.
User avatar (0015349)
StrikerMan780 (reporter)
2016-07-17 00:06
edited on: 2016-07-17 00:47

 When I did that, it merged all of 4.0 into the 3.0 fork I had and made a mess. I deleted everything, going to try again, this time just merging into a 4.0 fork.

EDIT: Ugh, I feel like this is just overcomplicating things. By now I would have just done needed changes in the 3.0 repo manually, and if merge conflicts arise in 4.0, discard the 3.0 version in favor of the one matching GZDoom.

EDIT 2: This is the best I can do. This is the 3.0 version of the code in the 4.0 zdoom sync branch following Torr's instructions the best I can. This won't compile as-is (at least I don't think), since it needs to be merged with 3.0.'https://bitbucket.org/jordon_moss/zandronum-zdoom-sync/commits/all [^]'

Torr is set as a repo admin for that fork.
User avatar (0015351)
Torr Samaho (administrator)
2016-07-17 07:05
Quote from StrikerMan780
When I did that, it merged all of 4.0 into the 3.0 fork I had and made a mess.

That's why I said "The "push" button in TortoiseHg will push everything you have locally to the target URL". I can fully understand that you are not familiar with the hg terminology if you never really used hg before, but "everything you have locally" shouldn't leave much room for interpretation...

Also, my first Google hit for "hg push selected commits" shows how you can do this, so I wonder what you tried to find out how to push just the four commits.

Quote from StrikerMan780
This won't compile as-is (at least I don't think), since it needs to be merged with 3.0.

The merging with 3.0 is what needs to be done in the grafting step. I will not pull anything that doesn't compile. If necessary, you can manually adjust the parts where the automatic merging done by graft produced non-working code, and use "amend" (that is the keyword to Google for) to include additional changes in the graft commit.
User avatar (0015352)
StrikerMan780 (reporter)
2016-07-17 07:11
edited on: 2016-07-17 07:14

 I got no results for how to just push the four commits in TortoiseHG.

The code will compile in 3.0. It just won't compile mixed in with all the 4.0 shit in the same repository.

*sigh* Guess it's time to try again for the 5th fucking time. Mercurial is a nightmare, I'm used to GIT. Then again, maybe if I wasn't such a stupid, braindead, worthless sack of shit I'd not have had any problems by now.
User avatar (0015353)
StrikerMan780 (reporter)
2016-07-17 07:48
edited on: 2016-07-17 09:10

 I think I may have finally got it, but it certainly wasn't straightforward.

I had to mark all previous 4.0 commits as secret, then mark my commits as draft, then "Detect outgoing changes to selected URL", which narrowed it down to my four commits, which I then pushed.

EDIT: The code compiles, it's merged in 3.0, but there's an oversight I made during the graft process. Am I allowed to make some additional commits on top, fixing these things? (Just small, they shouldn't be put in 4.0, though, since this is an issue with 3.0 exclusively.)
User avatar (0015354)
StrikerMan780 (reporter)
2016-07-17 09:08
edited on: 2016-07-17 20:04

 How's this?'https://bitbucket.org/Torr_Samaho/zandronum/pull-requests/126/surfaceskin-for-modeldef-zandronum-30/diff [^]'

EDIT: No?
User avatar (0015364)
Edward-san (developer)
2016-07-17 20:21

 Be patient, he'll reply when he has the time.
User avatar (0015369)
StrikerMan780 (reporter)
2016-07-18 05:45

 Sorry, just anxious... kind of burned out after dealing with the weirdness of HG, so I'm hoping that this push request was done right so I won't have to screw around with things and repeat the process yet again.
User avatar (0015391)
Torr Samaho (administrator)
2016-07-19 12:52
Quote from StrikerMan780
I got no results for how to just push the four commits in TortoiseHG.

FYI, the command line tools are part of TortoiseHG and my first Google hit for "hg push selected commits" shows how you can do this with the command line tools.

Meanwhile, I had a closer look at your pull request. So the fifth commit is supposed to fix the merge errors made in the first commit and thus should have been part of the first commit, right?
User avatar (0015394)
StrikerMan780 (reporter)
2016-07-19 15:10

 The 5th commit is to fix some things that were wrong that I didn't notice until after I compiled when I did the original graft.
User avatar (0015402)
Torr Samaho (administrator)
2016-07-20 11:36

 Then the 1st and 5th commit should be merged into one (which unfortunately also has consequences on some of the other three commits). Since you seem to be struggling with hg, I can probably do this myself, but it will take some time till I get around to do so.
User avatar (0015409)
Torr Samaho (administrator)
2016-07-23 16:31

 I merged the 1st and 5th commit, adjusted the others and pushed everything to
the sandbox. The end result should be identical to what you have in the pull request, just the history is cleaner. Can you confirm that this is working as expected? If so, I'll push this to our 3.0 repo and we are done.
User avatar (0015410)
StrikerMan780 (reporter)
2016-07-24 19:39
edited on: 2016-07-26 17:26

 Works fine (Compiled from the Sandbox build). Sorry it took so long to figure shit out with HG. It's much different than what I'm used to. (I'm used to GIT)

Issue Community Support
Only registered users can voice their support. Click here to register, or here to log in.
Supporters: StrikerMan780 Dark-Assassin
Opponents: No one explicitly opposes this issue yet.

- Issue History
Date Modified Username Field Change
2016-07-12 01:06 StrikerMan780 New Issue
2016-07-12 01:10 StrikerMan780 Note Added: 0015284
2016-07-12 01:10 StrikerMan780 Note Edited: 0015284 View Revisions
2016-07-12 01:13 StrikerMan780 Note Edited: 0015284 View Revisions
2016-07-12 01:14 StrikerMan780 Note Edited: 0015284 View Revisions
2016-07-12 01:19 StrikerMan780 Note Added: 0015285
2016-07-12 06:54 StrikerMan780 Note Added: 0015288
2016-07-12 06:58 StrikerMan780 Note Edited: 0015288 View Revisions
2016-07-12 13:02 Edward-san Note Added: 0015291
2016-07-12 13:33 StrikerMan780 Note Added: 0015292
2016-07-12 16:56 StrikerMan780 Note Edited: 0015292 View Revisions
2016-07-12 16:57 StrikerMan780 Note Edited: 0015292 View Revisions
2016-07-12 17:00 Dusk Status new => needs review
2016-07-12 17:22 StrikerMan780 Note Added: 0015294
2016-07-12 17:22 StrikerMan780 Note Edited: 0015294 View Revisions
2016-07-12 18:32 Torr Samaho Note Added: 0015295
2016-07-12 18:32 Torr Samaho Assigned To => Torr Samaho
2016-07-12 18:32 Torr Samaho Status needs review => feedback
2016-07-12 20:22 StrikerMan780 Note Added: 0015299
2016-07-12 20:22 StrikerMan780 Status feedback => assigned
2016-07-12 20:30 StrikerMan780 Note Edited: 0015299 View Revisions
2016-07-12 21:39 StrikerMan780 Note Added: 0015300
2016-07-13 18:09 Torr Samaho Note Added: 0015304
2016-07-15 01:27 Dark-Assassin Note Added: 0015309
2016-07-15 03:37 StrikerMan780 Note Added: 0015310
2016-07-15 03:38 StrikerMan780 Note Edited: 0015310 View Revisions
2016-07-15 03:38 StrikerMan780 Note Edited: 0015288 View Revisions
2016-07-15 03:41 StrikerMan780 Note Edited: 0015310 View Revisions
2016-07-16 04:48 StrikerMan780 Note Edited: 0015310 View Revisions
2016-07-16 04:48 StrikerMan780 Note Added: 0015325
2016-07-16 07:40 StrikerMan780 Note Added: 0015326
2016-07-16 15:21 Torr Samaho Note Added: 0015328
2016-07-16 16:34 StrikerMan780 Note Added: 0015329
2016-07-16 16:37 StrikerMan780 Note Edited: 0015329 View Revisions
2016-07-16 17:57 StrikerMan780 Note Edited: 0015329 View Revisions
2016-07-16 17:59 StrikerMan780 Note Edited: 0015329 View Revisions
2016-07-16 18:00 Torr Samaho Note Added: 0015330
2016-07-16 18:08 StrikerMan780 Note Added: 0015331
2016-07-16 18:09 StrikerMan780 Note Edited: 0015331 View Revisions
2016-07-16 18:10 StrikerMan780 Note Edited: 0015331 View Revisions
2016-07-16 18:13 Torr Samaho Note Added: 0015332
2016-07-16 18:17 StrikerMan780 Note Added: 0015333
2016-07-16 18:22 Torr Samaho Note Added: 0015334
2016-07-16 18:36 StrikerMan780 Note Added: 0015335
2016-07-16 18:36 StrikerMan780 Note Edited: 0015335 View Revisions
2016-07-16 18:37 StrikerMan780 Note Edited: 0015335 View Revisions
2016-07-16 18:38 StrikerMan780 Note Edited: 0015335 View Revisions
2016-07-16 18:40 StrikerMan780 Note Edited: 0015335 View Revisions
2016-07-16 18:41 StrikerMan780 Note Edited: 0015335 View Revisions
2016-07-16 18:43 StrikerMan780 Note Edited: 0015335 View Revisions
2016-07-16 18:50 StrikerMan780 Note Edited: 0015335 View Revisions
2016-07-16 18:55 Torr Samaho Note Added: 0015336
2016-07-16 18:55 StrikerMan780 Note Edited: 0015335 View Revisions
2016-07-16 18:56 StrikerMan780 Note Added: 0015337
2016-07-16 18:58 StrikerMan780 Note Edited: 0015337 View Revisions
2016-07-16 18:58 StrikerMan780 Note Edited: 0015337 View Revisions
2016-07-16 18:59 Torr Samaho Note Added: 0015338
2016-07-16 19:00 StrikerMan780 Note Edited: 0015337 View Revisions
2016-07-16 19:00 StrikerMan780 Note Added: 0015339
2016-07-16 19:02 StrikerMan780 Note Edited: 0015339 View Revisions
2016-07-16 19:09 StrikerMan780 Note Edited: 0015337 View Revisions
2016-07-16 19:11 StrikerMan780 Note Edited: 0015339 View Revisions
2016-07-16 19:12 StrikerMan780 Note Edited: 0015339 View Revisions
2016-07-16 19:12 Torr Samaho Note Added: 0015340
2016-07-16 19:14 Torr Samaho Note Edited: 0015340 View Revisions
2016-07-16 19:14 Torr Samaho Note Edited: 0015340 View Revisions
2016-07-16 19:31 StrikerMan780 Note Added: 0015341
2016-07-16 19:31 StrikerMan780 Note Edited: 0015341 View Revisions
2016-07-16 20:07 StrikerMan780 Note Edited: 0015341 View Revisions
2016-07-16 20:08 Torr Samaho Note Added: 0015342
2016-07-16 20:12 StrikerMan780 Note Added: 0015343
2016-07-16 21:03 Torr Samaho Note Added: 0015344
2016-07-16 21:06 StrikerMan780 Note Added: 0015345
2016-07-16 21:07 StrikerMan780 Note Edited: 0015345 View Revisions
2016-07-16 21:08 StrikerMan780 Note Edited: 0015345 View Revisions
2016-07-16 21:12 Torr Samaho Note Edited: 0015344 View Revisions
2016-07-16 21:16 Torr Samaho Note Added: 0015346
2016-07-16 21:18 StrikerMan780 Note Added: 0015347
2016-07-16 21:34 StrikerMan780 Note Edited: 0015347 View Revisions
2016-07-16 23:25 StrikerMan780 Note Edited: 0015347 View Revisions
2016-07-17 00:03 Edward-san Note Added: 0015348
2016-07-17 00:04 Edward-san Note Edited: 0015348 View Revisions
2016-07-17 00:06 StrikerMan780 Note Added: 0015349
2016-07-17 00:07 StrikerMan780 Note Edited: 0015349 View Revisions
2016-07-17 00:07 StrikerMan780 Note Edited: 0015349 View Revisions
2016-07-17 00:08 StrikerMan780 Note Edited: 0015349 View Revisions
2016-07-17 00:39 StrikerMan780 Note Edited: 0015349 View Revisions
2016-07-17 00:44 StrikerMan780 Note Edited: 0015349 View Revisions
2016-07-17 00:46 StrikerMan780 Note Edited: 0015349 View Revisions
2016-07-17 00:47 StrikerMan780 Note Edited: 0015349 View Revisions
2016-07-17 07:05 Torr Samaho Note Added: 0015351
2016-07-17 07:11 StrikerMan780 Note Added: 0015352
2016-07-17 07:13 StrikerMan780 Note Edited: 0015352 View Revisions
2016-07-17 07:13 StrikerMan780 Note Edited: 0015352 View Revisions
2016-07-17 07:14 StrikerMan780 Note Edited: 0015352 View Revisions
2016-07-17 07:48 StrikerMan780 Note Added: 0015353
2016-07-17 07:56 StrikerMan780 Note Edited: 0015353 View Revisions
2016-07-17 08:17 StrikerMan780 Note Edited: 0015353 View Revisions
2016-07-17 08:20 StrikerMan780 Note Edited: 0015353 View Revisions
2016-07-17 09:02 StrikerMan780 Note Edited: 0015353 View Revisions
2016-07-17 09:03 StrikerMan780 Note Edited: 0015353 View Revisions
2016-07-17 09:08 StrikerMan780 Note Added: 0015354
2016-07-17 09:10 StrikerMan780 Note Edited: 0015353 View Revisions
2016-07-17 20:04 StrikerMan780 Note Edited: 0015354 View Revisions
2016-07-17 20:21 Edward-san Note Added: 0015364
2016-07-18 05:45 StrikerMan780 Note Added: 0015369
2016-07-18 14:23 Torr Samaho Note Added: 0015373
2016-07-19 12:52 Torr Samaho Note Added: 0015391
2016-07-19 15:10 StrikerMan780 Note Added: 0015394
2016-07-20 11:36 Torr Samaho Note Added: 0015402
2016-07-23 16:31 Torr Samaho Note Added: 0015409
2016-07-23 16:31 Torr Samaho Note Deleted: 0015373
2016-07-24 19:39 StrikerMan780 Note Added: 0015410
2016-07-24 19:40 StrikerMan780 Note Edited: 0015410 View Revisions
2016-07-24 19:40 StrikerMan780 Note Edited: 0015410 View Revisions
2016-07-26 17:26 StrikerMan780 Note Edited: 0015410 View Revisions




Questions or other issues? Contact Us.

Links

Copyright © 2000 - 2024 MantisBT Team
Powered by Mantis Bugtracker