11 réponses à ce sujet

[Challseus]

All,

Now, I'm not sure if I am interpreting this correctly, so just bear with me. So, I find myself in the somewhat annoying position where I may need to override ability_core.nss. Messy stuff, yes, I know, but I don't see any other way around it.

Anyway, I am able o view the script itself in the toolset, but I notice there is a big red dot next to the name of it in the palette window. Now, I've never really paid much attention to that before, but I do see it on various designer resources. Anyway, when I attempt to check the resource history, it only shows one entry date, which I "think" is the last time I ran a DB backup. To be clear, I have never loaded up things for my module via a B2B update. I've always just restored the DB.

So:

1) What happened to the history of this file (presumably, Georg didn't write the entire thing in one go!)
2) How can I get that back? Do a B2B load of the core resources (I think there is a project somewhere around here that will take care of that)

Thanks.

Modifié par Challseus, 18 février 2011 - 08:25 .

[ladydesire]

I'm going out on a limb here (hopefully not a short limb ), but I believe the database included in the toolset does not have the full edit history from the main build database at Bioware. The reason I say this is that most core files don't show any major edits in my database.

[Challseus]

Interesting... Do they have red dots next to them? I guess my major issue is, I want to check out ability_core.nss, edit it, then check it back in. I simply do not have the ability to do this at the moment.

[Proleric]

My core resources generally have a red dot above a green dot on the grey disc drive icon.

I can check out ability_core.nss and edit it.

The resource history shows two Bioware entries (user : outsourcetest) on 12-Dec-2009, which, as ladydesire suggests, might be the date it was added to the toolset from the Bioware in-house data base.

Two obvious questions. Why would you need any earlier history? Why overwrite the script?

A possible workaround is to duplicate the core script into a new resource with a different name in your module, edit & compile, then change the name of the .ncs file in your module override folder to ability_core.ncs. As you know, that's not best practice. So far, I've always found a cleaner way...

[Challseus]

Proleric1 wrote...

Why would you need any earlier history?

Oh, I don't need an earlier history, per se. I'm just thinking it's indicative of a much bigger problem with my core resources in general, if I can't see the history. As I said, I can't check it out to make copies to it, which depending on if that is the best course to take, I should at least be able to do.

Proleric wrote...
Why overwrite the script?

Ah, the million dollar question  To be fair, even touching core resources is against my religion, and I've been able to stay away from it for over a year. This particular issue I've been mulling over for months, and have finally decided to just do it. But, perhaps I am wrong, and talking it over will present a better solution.

Anyway, as far as I can tell, all ability use will be funneled into ability_core.nss. I've done all sorts of things after that script runs, but now, I want to actually change how one event, EVENT_TYPE_ABILITY_CAST_START works. I've been able to override the engine event, EVENT_TYPE_COMMAND_PENDING with no issues, but the former one just doesn't seem to work.

So since I cannot re-route the processing of the event into my own script, my only course of action (that I know of) is to just make my own edits to it. Very ugly, not proud of it, but I don't see any other way. On the plus side, my game is a fully standalone game, so I shouldn't (hopefully) have to worry about messy conflicts.

Proleric...
A possible workaround is to duplicate the core script into a new resource with a different name in your module, edit & compile, then change the name of the .ncs file in your module override folder to ability_core.ncs. As you know, that's not best practice. So far, I've always found a cleaner way...

Interesting... That's exactly how I get my pre-gen character to work, never thought of this. As you say, not a clean way, but it could work...

[Proleric]

Understood.

You should be able to duplicate, even if you can't check out.

If that doesn't work, I guess the last resort is to archive your work in B2B format, then rebuild the data base from scratch.

Incidentally, just in case it's my data base that's abnormal, can anyone else confirm that you should be able to check out core resources?

[-Semper-]

yup, there's something wrong with challseus' database. no problem to check out/in core scripts. you can also dublicate read only resources without any issues.

[Sunjammer]

From what I've seen working with other builder's databases and my own team server Resource History does not include check-outs from other user accounts (i.e. other than your own). In other words while it will include a "green tick" check-out, it won't include a "red dot" check-out. Obviously these are just my observations - I haven't tested it to any extent since it's not really an issue (see below).

Fortunately you you can get the user information from the bottom section on the General the resource's Properties (right-click on the resource -> Properties). There you'll see the Checked Out By and Checked Out On information which might give you a clue as to who checked out the resource and may then also offer you a simple solution (for example if it is one of your other user accounts).

However if there is no simple solution then you can none the less brute force the check-in - I've had to do it where I've been sent databases with resources checked out by builder's who are no longer part of team I'm helping. I can send you an example query if you like. It may also be possible to brute force an undo check-out which might be a more appropriate option.

Modifié par Sunjammer, 20 février 2011 - 02:26 .

[Challseus]

Thanks to everyone for their input. Looks like I'm going to go with the 'rebuilding the database' solution since mine clearly got FUBAR'd at some point.

[Challseus]

Sunjammer wrote...

Fortunately you you can get the user information from the bottom section on the General the resource's Properties (right-click on the resource -> Properties). There you'll see the Checked Out By and Checked Out On information which might give you a clue as to who checked out the resource and may then also offer you a simple solution (for example if it is one of your other user accounts).

Now this is interesting. I get the following info (GameCoder is me):

--------------------------------------------------------------------------

Created By: OUTSOURCETEST\\outsourcetest
Created On: 12/9/2009 10:24:22 AM

Checked Out By: GAMECODER\\GameCoder
Checked Out On: 12/15/2009 3:11:15 PM

Last Checked In By: OUTSOURCETEST\\outsourcetest
Last Checked In On: 12/9/2009 2:09:22 PM

--------------------------------------------------------------------------

Now, I can assure you that I have never checked out this file, and if I had, I should be able to check it in, no?!

Also, to your other question (from the PM) about importing the 1.01 core and single player resources, I'm pretty sure I did that when they were initially released. If I tried again, presumably, it would overwrite the existing stuff? That may be a good solution as well (I haven't done the DB thing yet)...

[Sunjammer]

Challseus wrote...

Also, to your other question (from the PM) about importing the 1.01 core and single player resources, I'm pretty sure I did that when they were initially released. If I tried again, presumably, it would overwrite the existing stuff? That may be a good solution as well (I haven't done the DB thing yet)...

Since the resources are checked out reimporting isn't an option - if you try it you will end up with a duplicate of every resource (also checked out) but with a "_1" suffix. Then you really will be in a pickle!

What you might try is looking at the other modules in your database Demo, Single Player,etc. and see the "green tick" check outs are in those modules (i.e. try finding the module you had open when you imported). If they are then you can do a mass check-in (i.e. select everything (which you should be able to do by going to the All palette and selecting the top level folder(s)) and then check-in).

I'm not sure if this will work - I'm AFT at the moment and so unable to test - as my recollection is that when you inherit you can check things in and out of the Parent module from the Child module (i.e. a check out in one appear as "green ticks" in the other).  Even if you aren't inheriting from SPC then you will be inheriting from Core and ability_core is presumably a Core resource so I would have expected it to be a "green tick".

Still nothing ventured ...

Modifié par Sunjammer, 21 février 2011 - 10:50 .

[Challseus]

*Cough*

So yeah, I'm clearly late as all hell, but I finally had to face my fears and fix this problem to take care of 2 nasty bugs. Proleric's suggestion of creating my own file, then renaming it to be one of the core files ended up working.

Well, for what it's worth, was nice to take a trip down memory (took me an hour to find this thread!).