Highres access by modders.

[TerminX]

ProAsm said:
The models need to be rejected before they are even created.

I don't think they do. They certainly don't actually get loaded into the game via my method AFAIK. I had to create undefmodel because I was running into the same problem you're experiencing, but with Duke. I don't think something like your rejectmodel method is appropriate because it requires you know the actual filename of what you're rejecting.

[ProAsm]

I dont need the filename, I need the string that the model was defined at in the first place.
The filename is always reject.def
Reject.def has all the definemodel's in it except with a rejectmodel command.
just before a model now gets loaded it goes to look if its define string is in this file:

            case T_DEFINEMODEL:
            {
            char *modelfn;
            double scale;
            int shadeoffs;

            if (scriptfile_getstring(script,&modelfn)) 
               break;
            if (CheckForRejects(modelfn))
               {
               initprintf("Rejected: %s\n", modelfn);
               return -1;
               }
            // continues here if not rejected...
            }
                 
// down at the end of defs.c

int CheckForRejects(char *def)
{
    scriptfile *script;
    int x;

    script = scriptfile_fromfile("reject.def");
    if (!script)
        return 0;

    x = rejectparser(script, def);  // my own parser
    scriptfile_close(script);
    scriptfile_clearsymbols();
    return x;
}

The only problem here is everytime a new MD2/3 is brought out the definemodel string needs to be added to the reject.def file which I suppose is not a problem but using a tilenumber would be better.

This way works a treat - for now

[djimd]

Now that you have models working have you tried to get the Lonukem models to show instead of the textures that you replaced them with?

[ProAsm]

LoNukem, models ? - I did not know I had models in there, I'll go have a look
I did do RW.

What I have also done now is that SWP will look in 2 places for rejects.
1. It first looks for the reject.def which can just be added to a ZIP or GRP file.
2. If it does not find that it will look for a filename which is the same as the ZIP/GRP filename from the same path.
So if it is C:\JFSW\Games\Rampage.grp it will look for C:\JFSW\Games\Rampage.rej
This is so one can have several different reject filenames for each TC which you just update as new MD's are made for the game and as long as it sits in the same folder as the ZIP/GRP file.
I had to use a .rej extension because the TCName.def is already used which I'm sorry about now, should have just stuck to User.def at the time.

[Parkar]

ProAsm said:
I patched all the relavent stuff related to the undefmodel but it did not work.
The models need to be rejected before they are even created.
Currently the undefmodel works ok as a undeftile although tiles can be overwriten making the command redundant.

But why is that needed? Placing the undefmodel command in the user.def and it will be loaded after the HRP def files.

[ProAsm]

Its not needed.
The only way this can be done successfully is the way I've now done it in Swp and thats a lookup table stopping the creation of a MD2/3 model.
It works great so release your HRP whenever you are ready and all we need is a include User.def after the HRP

[TerminX]

ProAsm said:
Its not needed.
The only way this can be done successfully is the way I've now done it in Swp and thats a lookup table stopping the creation of a MD2/3 model.
It works great so release your HRP whenever you are ready and all we need is a include User.def after the HRP

No, sorry, but contrary to your belief undefmodel works fine. I've even added an undefmodelrange to take care of entire enemies at once. Not only does it not require some messy reject system, but it doesn't require a constantly updated list of rejections either. Models do not need to be rejected before they are "created."

Simply put, my way is better as it is faster and it is simpler. I've updated the patch to include undefmodelrange. Syntax is as follows: undefmodelrange tilenum1 tilenum2. That's it. As an example, to prevent the basic ninja from EVER using a model, this single line in user.def will do it: undefmodel 4096 4239. Much cleaner than having some filename specific reject.def.

[ProAsm]

Well can you post the files as the patch.exe does not work for me even though JF gave me his latest.
When I saw your patch work I did not want to patch my code as you have a lot of patching there so I did manually only what I thought was needed and thats probably where I went wrong.
I would very much like to try your way as any way is fine by me.
But to come out and accuse my work of some "messy reject system" I dont think is called for, as I at least made an effort to improve the game as that is what this development forum is abouut or am I seriously mistaken.
During all the time when we were debating the problem not once did you offer a hand or give some advice, then suddenly you mention some undefmodel as if its been around since dot.

[TerminX]

ProAsm said:
Well can you post the files as the patch.exe does not work for me even though JF gave me his latest.
When I saw your patch work I did not want to patch my code as you have a lot of patching there so I did manually only what I thought was needed and thats probably where I went wrong.
I would very much like to try your way as any way is fine by me.
But to come out and accuse my work of some "messy reject system" I dont think is called for, as I at least made an effort to improve the game as that is what this development forum is abouut or am I seriously mistaken.
During all the time when we were debating the problem not once did you offer a hand or give some advice, then suddenly you mention some undefmodel as if its been around since dot.

I'm not sure where you can get a working GNU diff/patch toolset for Windows. I do all of my patching (including generating the diff) on my Linux box. Just go through and apply the changes to defs.c and mdsprite.c by hand (there aren't too many). I've only said your reject system is messy because it requires you know the exact filename -- I would say mine is messy as well because it doesn't unload the model, et cetera, but it's far simpler from the user's standpoint.

Edit: by the way, I found and corrected a typo in the patch (the last tile of the range to undefine wasn't getting undefined, accidentally put a < instead of <=, find "i<tilenume2" in defs.c and replace it with "i<=tilenume2")

[ProAsm]

JF gave me 2 Patch.exe's - one is 79k and the other 59k with the 59k being the latest.
The 79k one does nothing whereas the 59k one starts to do its job then it crashes out with some error about cannot find some file.
The missing part you mentioned might be the key as a lot of the stuff went in the defs.c although during the manual patching of the build.c I did see something very wierd which did not make sense, I'll see if I can dig it out and show you.
I dont think your way of not unloading a model would be too serious (hope not) - time will tell

*** Edit ***

Edit: by the way, I found and corrected a typo in the patch (the last tile of the range to undefine wasn't getting undefined, accidentally put a < instead of <=, find "i<tilenume2" in defs.c and replace it with "i<=tilenume2")

Help me here, I checked this and I dont have a mention anywhere in defs.c relating to tilenume2, and I dont find it in the patch either ?
Also the other stuff in the defs.c is it needed or related to the T_UNDEFMODEL like the ALPHAHACK etc ?

*** Edit 2 ***

Ok it looks like you have maybe a previous patch for the defs.c which incorporates whatever section you speak of with the tilenume2 above.

With the small inclusion of your patch in the defs.c and mdsprite.c things started happening here but all I managed to see was the actual 4096 sprite and the rest was still the new Ninja MD2.

So what I did, which you obviously have somewhere else is incorporated a range in the undefmodel.

In your case I assume the command would be 'undefmodel 4096'
What I now did is 'undefmodel 4096 4240' so this whole range is now undefined.

    case T_UNDEFMODEL:
    {
      int i;
      int tilenum1, tilenum2;

      if (scriptfile_getnumber(script,&tilenum1)) break;
      if (scriptfile_getnumber(script,&tilenum2)) break;

      if (tilenum1 >= 0 && tilenum1 < MAXTILES && tilenum2 > tilenum1 && tilenum2 < MAXTILES)
         {
         for (i=tilenum1; i<tilenum2; i++)
              tile2model[i].modelid = -1;
         }
    }
    break;

Congratulations - it works brilliantly and as you say it can be implemented anywhere

[TerminX]

ProAsm said:
What I now did is 'undefmodel 4096 4240' so this whole range is now undefined.

    case T_UNDEFMODEL:
    {
      int i;
      int tilenum1, tilenum2;

      if (scriptfile_getnumber(script,&tilenum1)) break;
      if (scriptfile_getnumber(script,&tilenum2)) break;

      if (tilenum1 >= 0 && tilenum1 < MAXTILES && tilenum2 > tilenum1 && tilenum2 < MAXTILES)
         {
         for (i=tilenum1; i<tilenum2; i++)
              tile2model[i].modelid = -1;
         }
    }
    break;

Congratulations - it works brilliantly and as you say it can be implemented anywhere

That was already in the patch I linked you to. I suggest you download the patch again to see the "undefmodelrange" I talked about adding. That's almost the exact code I'd written, but yes, it does work brilliantly and as stated it can be implemented anywhere after the model is defined.

[ProAsm]

No, I just checked now again and there is no mention of undefmodelrange anywhere.
Could you update please so I can have a look.
On the otherhand would a single undefmodel not be better that can take either a single tile or multitiles, saves the 'brainbox'
Code changed to following to accomodate this.

    case T_UNDEFMODEL:
    {
        int i;
        int tilenum1, tilenum2;

        if (scriptfile_getnumber(script,&tilenum1)) break;
        if (script->textptr + 1 >= script->eof) // incase only 1 entry
            tilenum2 = tilenum1 + 1;
        else
        if (scriptfile_getnumber(script,&tilenum2)) break;

        if (tilenum1 >= 0 && tilenum1 < MAXTILES && tilenum2 > tilenum1 && tilenum2 < MAXTILES)
           {
           for (i=tilenum1; i<tilenum2; i++)
                tile2model[i].modelid = -1;
           }
    }
    break;

[TerminX]

ProAsm said:
No, I just checked now again and there is no mention of undefmodelrange anywhere.
Could you update please so I can have a look.

It's been updated in the patch for two days now. I suggest you clear your cache so you don't appear quite as confused.

[ProAsm]

mmm ok let me try again as the one I have is 65,836 bytes long.

*** Edit ***

Ahhhhhh I see now...
One needs to Ctrl refresh

*** Edit 2 ***
A query and a suggestion.
Is the T_UNDEFTEXTURE necessary as the T_UNDEFMODEL basically does the same job or what ?
I suggest the 2nd tile check may be an improvement on the current incase someone makes the second figure smaller than the first ?

if ((tilenume >= 0 && tilenume < MAXTILES) && (tilenume2 >= 0 && tilenume2 < MAXTILES))
if ((tilenume >= 0 && tilenume < MAXTILES) && (tilenume2 > tilenume && tilenume2 < MAXTILES))

[TerminX]

Undeftexture undefines a hightile replacement.. like for textures or whatnot. Good catch on the check for tile numbers. I'll just make it correct it and spit out a warning like the other stuff in the defs system does.

[ProAsm]

Yes I only saw the stuff about the hightile once I got the error as I did not see to update the hightile.c
Ok I'll get this lot together now and also neaten up the code and remarks etc then attach it on the next update of Swp.
Thanks for the help on this lot - works great

[TerminX]

ProAsm said:
Yes I only saw the stuff about the hightile once I got the error as I did not see to update the hightile.c
Ok I'll get this lot together now and also neaten up the code and remarks etc then attach it on the next update of Swp.
Thanks for the help on this lot - works great

No problem. If you use the alphahack stuff (highly recommended for things like cracks on the wall, et cetera) make sure you update polymost.c as well.

[Parkar]

The mod support in the HRP is changeling as of the next HRP beta for duke. The changes are not huge and will make it easier for people making mods that depend on or can be used toghter with other mods like say a map pack for a mod etc.

The user.def is gone and instead the mod will have a sw.def file and a main def file of the mod like mymod.def. mymod.def would essentialy be the user.def file. the mymod.def should have include lines for each mod it can be loaded with. Lets say we have a mod named mymod and a map pack for that called mymappack.

The mod will have 2 def files tighter with all the other contents in the mod.

sw.def

 // Includes the hrp main def file encase the hrp is loaded
include sw_hrp.def
// then loads the main def of the mod
 include mymod.def

mymod.def that has all the definitions etc for the mod.

The map pack will in the same way have 2 def files.

sw.def

 // Includes the hrp main def file encase the hrp is loaded
include sw_hrp.def
// then loads the main def of the mod since the mod sw.def is no longer being used
include mymod.def
// and finally loads the map pack main def file
include mymappack.def

This whole system will work a lot better with launchers later on since the launcher will just generate the sw.def file before starting the game. what it will do is basically add an include to every mod map pack etc that the user selects and add the includes for this to a temp def file and launch the game loading the zip and grp files for these mods and tell it to use this def instead of sw.def. I'll let JonoF go into detail on this once it will work in a released jfsw.

[ProAsm]

You say a line gets added to the sw.def like:
include mymod.def
How does that line get there, from a "launcher" - what launcher ?
Are you saying each mod that is produced now needs a launcher to create a new sw.def with this line added, or each mymod.zip or mymod.grp file has its own sw.def file because this wont work as sw.exe does not accept user sw.def files in the grp file.
If however you are saying that a "launcher" will now create this sw.def file then that is a bad bad idea, and the reason I say that is as follows:
I had this problem with SwGroup in the beginning back in 1998.
SwGroup as you probably know, created a startup mymod.com file which inturn renamed the current sw.exe file to something then created a new sw.exe which launched the game.
Whan the game ended this situation was reversed again and all worked well until the user had a desktop crash (DOS crash back then) or a power failure and his PC rebooted.
Now this newly created Sw.exe file was there but the user was none the wiser.
SwGroup now had a hell of a lot of error checking in it, looking to see if a power break or a crash occured.

The same thing looks to be happening here where a launcher of some description, possibly a batchfile will create this sw.def file.
What happens after a desktop crash to the sw.def file ?

I still say either the Sw.exe should do the job of looking for a mymod.def or we just leave things as they are with the current include user.def as it does work and it works well, and also we dont have to go and change all the current TC's again because the chances of any new TC's being made for the game is very small.

[Parkar]

I think you misunderstood what I meant.

Yes each mod will have a sw.def file, the game will use the last sw.def loaded. ie sw /gmod1.zip /gmod2.zip would mean that sw.det in mod 2 will be loaded. If this don't work you should let JonoF know about it coz he is the one who came up with this solution.

The launcher is not realy needed if you are an advanced user. the launcher will not overwrite the sw.def it will create a file named say launcher.def and then launch sw with /hlauncher.def to make it use that def instead of the sw.def file. The launcher will use a text file in the grp/zip file to tell the launcher what the main def file is called and some other info like mod name etc. Since I think JonoF is completely done with the specifics yet I am not sure if he changed this.

the user.def system is a bit limited if you ask me and will means the mod will need the HRP to work with high tile since it does not have sw.def file.

the new system will work just as fine as the user.def but it moves the mod functionality to the mod instead of the HRP which is a better solution I think. Also if you want to load 2 mods of some reason the user.def system will not work since both mods will use the same def file making only the last one be used.

With the new system a mod and HRP would be loaded just like with user.def.

sw /gsw_hrp.zip /gmymod.zip

The game will read the sw.def in the last listed mod which includes the main def in the other mods before it.

If you want to load 2 mods that does not collide you just make a separate def file like test.def in that you include the main defs of the mods you want to load like this.

sw /gmod1.zip /gmod2.grp /htest.def

This is the functionality that could be automated with a launcher.

Note that /h is not implemented in the current version of jfsw and I am not sure if I remember correctly, may have been /d or some other character.

If something other then /h does not work then that's a bug that JonoF needs to fix.

Ohh, and there will be a launcher in the HRP for both sw and duke. (excluding currently under way duke HRP version)

[ProAsm]

If this don't work you should let JonoF know about it coz he is the one who came up with this solution.

Correct, this does NOT work.
The way Sw.exe is currently, it will ONLY accept the Sw.def in the SW root folder and your Mod's /gwhatever.zip Sw.def is completely ignored.

I think you guys are now going completely overboard and getting very complicated, thus in my book either Sw.exe looks for the Mymod.def or it stays the way it is with the User.def
Why on earth would you want to load 2 mods.

I like the /h or /d option for loading a .def file but when I suggested it at the time with a /z command (which Duke3dw still uses) I got shot down in flames
Anyways if this /h is incorporated then that will be fine as thats all you will need.

[Parkar]

Thats strange coz the HRP for duke uses a duke3d.def inside the duke_hrp.zip and it works perfectly.

There may not be a reason for loading more then one mod for sw but the probalem is going to be there with Duke for sure with things like the gore pack and other mini stuff that might be used toghter with a more convetional mod.

If you ask me its just as simple as the user.def system. The launcher is just an optional add on that does not need to be used.

All a mod maker needs to worry about is the sw.def file not containing the actual definitions. The mod should still have a sw.def just to make launching it as easy as using /gmymod.grp.

The /h would just be used for more advanced things or a Launcher. I think JonoF already has the /h implemented by the way.

Should point out that this is nothing that's just been thought up, this is how JonoF has been meaning to suport mods and had I known it(or thought of this my self) from the start I would never have used the user.def.