Highres access by modders.

[ProAsm]

This is just something I have to say and I'm gonna say it even if it means being blown away.

JFSW is the new kid on the block and the number of interested followers is increasing daily, this I can tell by the downloads on my site, whereas Duke3d is basically dead and the code and textures are no where near complete, not to mention the monsters.
Approx a year ago, JFDuke3d also had many (1000's) followers but people cannot wait forever for models, correct code etc to play the game.
They want to play it NOW and NOW is the time to strike.
I see many people downloading maps (many maps) and Total Conversions and everything they can lay their hands on for JFSW.
The reason for this is they want to play the game NOW, not next month or next year but NOW.
This is great news for everyone, especially the modellers, texturers, coders and alike.
The problem comes in that within 6 months, all maps, TC's, Addons, etc have been played and the interested followers leave, leaving us with a handfull of people like with Duke.

What keeps a game alive ?
How well the game is presented .... 30%
How good the textures and models are .... 30%
TotalConversions/Addons/Usermaps .... 40%

When the current monsters where done for Duke3d, (Commander, Pigcop, Shark, Octabrain and Trooper mainly) the game took off like a rocket, I remember between October and January I played approx 50 TC's and about 500 maps and thats me done.
Like in any other game, its the modders/mappers/coders that keep a game interesting and alive and that brings me to the point I want to make here.
The way in which the Highres folders are structured for Duke makes it impossible for a modder to incorporate his TotalConversion or any conversion for that matter.
The reason is when the default game has new monster etc with a MD2/MD3, the TC/Addon cannot over-write this monster making the TC redundant.
Those of you that have the new Ninja installed and have played Rampage Warrior will understand this problem.
It is therefore very very important that a modder can simply modify the Monsters folder and/or any other new Textures that the default game has.

It is for the above reasons, that I beg you Parkar to reconsider your Folder and Def file makeup for JFSW before we fall in the same trap as with JFDuke3d.
I dont have any answers or better ideas, but the number of total folders should be kept to a minimum because whatever you do in your very first pack will become the standard forever.

Somethings to take into consideration.
JFSW will always use the folders default Sw.def file, even if a modder incorporates a new one in his TC.
However maybe the Sw.def should first call a Highres.def in the Sw root folder so that the modder can intervene here.
This Highres.def will then have the Major .def Includes
Example:

Sw.def file (in root folder)
include Highres.def

Highres.def file (in root folder)
include highres/screen.def
include highres/skyboxes.def
include highres/sounds.def
include highres/sprites.def
include highres/monsters.def
include highres/pickups.def
include highres/fonts.def
include highres/textures.def
include highres/whateverelse.def
include User.def

definetint 14 255 110 80 0

In this way the modder can duplicate this Highres.def in his GRP or ZIP file and remark out the monsters or whatever and add his own and any default one he likes.
The problem is a modder only has access to whats in the ROOT folder and subfolders are out of bounds.
Perhaps even the Monsters.def or any other def file that could have MD3/2's should also be left in the root folder so modders can directly change them.
Someone mentioned an idea about a Reject file which too is an excellent idea.
Please add comments/flames etc so we can all move forward together regarding the texture folder and file layout, because some current TC's are already going to need modification again as MD2/3's are added to the game.

[hitman71]

SO the HRP overrides modded textures etc in a TC ? If so, then i agree with the above and a diff way of doing things is required.

However, the HRP could be installed into the standard jfsw install and played...

And the TC's could be installed to a second jfsw install to get round this. Maybe all the art in TC's should be updated just like the main sw.grp's art files.

Is it possible to call a certain def file to load a certain set of textures etc depending on the TC loaded ??? Like having a texture folder within the TC's folder that is auto loaded ?

I think maybe the way all this works probably stops any other method from being used. The file structure is just the way it is...

[Parkar]

I am aware of the mod problems in the HRP and there will not be any HRP releases (duke/sw) until I figure out a way to fix this.

The sw.def file should be possible to owerwrite as long as its kept in a zip file just like with duke. just remeber to load the zip files in the correct order.

The thing that I missed is that that model defs can't be overridden so you need to create the same def files as in the HRP to make it HRP compatible. This was not intended since I was under the impression the latest def would be used both with models and textures but it only works with textures.

When it comes to the folder structure I know it has some problmes I did not forsee when I changed it from the old models/newtex solution. I somewhat regret changeing it coz of this since there is not as much gain in updateing the pack as I expected and this was the main reson for doing it. It has made it somewhat easier to keep updated though, especialy when trying to find stuff but this is mainly coz of the new naming convention and not the folder structure.

I see what you mean with the game not being followed by a lot all the time but since we are just doing this as a hobby I don't see anyway of overcomming it and I just keep at it for my own enjoyment. If/When ever I don't enjoy playing/working on duke/sw someone else will have to take over the HRP. I don't see this happening anytime soon though.

[ProAsm]

I am aware of the mod problems in the HRP and there will not be any HRP releases (duke/sw) until I figure out a way to fix this.

I am very pleased to hear you say this and this time let the modders and TC makers help in designing how to do this.
I will make a tiny TC to demonstrate and to test the results if need be, but lets get it right.

The sw.def file should be possible to owerwrite as long as its kept in a zip file just like with duke. just remeber to load the zip files in the correct order.

Unfortunately this is not possible as the Sw.def file in your root folder takes priority regardless of what you have in the GRP or ZIP files.

The thing that I missed is that that model defs can't be overridden so you need to create the same def files as in the HRP to make it HRP compatible.

Yes this is 100% correct, new Textures in the User.def file can override anything declared before that but not an MD2/3 model.
I wrote to JF about this for Duke3d but I dont think he saw the problem, thats why I wrote Duke3dw but it was way too late, I should have done that months ago.

I see what you mean with the game not being followed by a lot all the time but since we are just doing this as a hobby I don't see anyway of overcomming it and I just keep at it for my own enjoyment.

Yes I go it for my enjoyment at well but one likes to at least see something come of you hard work.
Like with Duke3d now, TC's which change monsters etc are impossible so the game comes to a grinding halt.

If/When ever I don't enjoy playing/working on duke/sw someone else will have to take over the HRP. I don't see this happening anytime soon though.

And lets hope you do keep going as we all need a "Master of ceremonies" and you fit that just great
Btw, your current folder structure is brilliant for the Developer Team, but unfortunately the Team is public so hence it always needs to look like the final release

Is it possible to call a certain def file to load a certain set of textures etc depending on the TC loaded ??? Like having a texture folder within the TC's folder that is auto loaded ?

I think Hitman might have hit on a good idea here and JonoF needs to change the way SW starts up by calling seperate DEF files in a sequence hence allowing a modder to intervene with his special.

I think maybe the way all this works probably stops any other method from being used. The file structure is just the way it is..

Agreed, but the way the files are added to what folders we can change.

[Parkar]

Unfortunately this is not possible as the Sw.def file in your root folder takes priority regardless of what you have in the GRP or ZIP files.

Well then its in the "wrong" place. It should be in a zip file.

I plan to make a beta version of the next HRP so I can get help testing it and makeing it work properly with mods etc before making the official release.

[ProAsm]

The sw.def file should be possible to owerwrite as long as its kept in a zip file just like with duke. just remeber to load the zip files in the correct order.

Maybe I'm not understanding you correctly here.
When you say kept in a zip file... what zip file are you refering to ?
Also what correct loading order are you refering to ?

Sorry if I'm a bit vague but my nVidia ti4200 has just crashed and all I had was a 4 bit 800x600 mode.
Fortunately my mobo has a Intel 82865G 64 meg graphics controller on board so that will keep me going till I can get another decent card.

[djimd]

I picked up on Parkars zip idea earlier and it solves the problem 100% -
In root folder i have sw.def:

include user.def

Also in root folder a zipped user.def called user.zip:

include highres/skybox.def
include highres/monsters.def
include highres/models.def
include highres/textures.def
include highres/fonts.def
include highres/props.def

Then I start the game with a shortcut to sw.exe (actually swp.exe ) - /guser.zip

Then any mod has its own user.def included on it's group or zip.

[hitman71]

but then wouldn't all the mods have to be named user.zip ? how would you call individual mods and activate their own def files ?

[Parkar]

This is how I intended mods to work (note: it does not work coz of the model problem)

The HRP would come with a sw_hrp.zip which contains all the textures/models/def files including the sw.def file.

To start sw with the HRP you run it with /gsw_hrp.zip

sw.def in the hrp zip includes the user.def but it has not user.def itself.

If we want to make a small mod which is basically an extra map with some extra textures we make a user.def which contains all the defs for the mod's own textures. put the map, art file, hires textures and the user.def into a zip file called mymod.zip(can be named what ever you want. To start the mod run sw /gsw_hrp.zip /gmymod.zip)

If we want run a mod with new art for the monsters without havering them replaced with the modelled monsters we need to add the highres/sprites/monsters.def to the mod so it will be used instead of the HRP monster.def file.

If we want to just replace a model/texture with our own highres model/texture we can can put new define lines in the user.def and these will be used instead. This is were the models fail since it does not work to replace the models in the hrp this way. You can how ever extract the def with the model you want to replace and put a copy in your mod and just edit it so it uses the new one but this has the disadvantage of losing compability with never releases of HRP.

I have been thinking of making a small example mod to show how to set it up.

[ProAsm]

Well let me explain what really happens from a modders point of view.
Firstly as I said before, the Sw.def (or Duke3d.def) takes the highest priority and it loads regardless of how many zips, user.def's or any other file you can think of.
This Sw.def is the problem, because at this point the MD2's are already loaded.

Now I want to add my TC, this TC changes the models with new MD2's or just a sprite like the original game.
This TC also has some new textures, weapons and pickups.

Currently I have no choice but to use the include User.def option but my new characters which replace the Ninja are not going to show.
All other textures that do not have MD2's are no problem and will be replaced with what I want as it will always accept the latest:
definetexture 3547 0 0 0 -1 -1 highres/textures/3547.png

If it could do this with MD2's then all our problems would be solved but only JF or Ken can do this for us or maybe I can try and incorporate it into Swp.

But at the moment what I need to do is disable the line that says include Monsters.def and maybe even the include pickups.def and probably also the include props.def
Currently that is not possible because these lines are in def files out of the root SW folder and down somewhere in the Highres\whatever\whatever\..... folder.

It is pointless saying use someones (Parkar) zip idea etc etc, because most players wont have this and probably dont know about it anyway.
Already some people have different folders, just look at the def files and models being supplied on this forum, the folders and hires includes that dont even exist are plentifull and erros are creeping in all over the place.

We need a standard and we need it NOW like this week as whatever the modellers/texturers give out as a Highres folder reference becomes the standard and this is where Duke3d went wrong.
We just cannot allow that to happen here and some sort of order needs to be put in place like anyone releasing textures etc release only its def file and graphics/MD2 and make no mention of the Highres folder names as its causing total chaos.

The only option at the moment is as I mentioned before that the Sw.def only has one line:-
include Highres.def

Another option is that JF and I in Swp add a line in the startup code in that if a Highres.def is available the Sw.def does NOT get loaded at all.

This Highres.def must include at least these 3 lines:
include highres/monsters.def
include highres/pickups.def
include highres/props.def
and every other def file that could possible have MD2 files.
In fact if we only had one like include models.def and every MD2 goes here and no where else would also be a way out.
That is what we had in Duke3d in the beginning and it worked like a charm until the HRP.
It is VERY important that these includes are directly in the ROOT folder like in the Highres.def file and not way down in the sub folders.

The other option which I'm looking at the moment is a:
rejectmodel "highres/sprites/monsters/4096_evilninja2.md2"
This too would solve all the problems but is gonna take time.

[djimd]

I've tried out your new swp.exe a little more - experimenting with the placement of defs. If i run sw.exe /guser.zip (with all highres options defined in user.def(zipped)) then all highres options show up. However if i run the same with swp.exe /guser.zip all highres except the props models show up - as you say the .md2 do not show. I suspect that you may have changed or missed something when re-compiling jf's sw.exe bcause that definitely shows .md2s when defined from within a zip.
Hopefully you can fix this because your "extras" and new hud look are great - the original megasize hud sucks big-time.

[hitman71]

Rather than go off at a tangent from JonoF's port, why not offer up the new hud and source changes to be included in his next release. Its nice to have a hobby you enjoy, and i'm sure its an improvement, but look whats happened with Mame. Theres now 6 billion diff versions all with their own little additions and tweaks. I never know if i'm missing out now (i always use official build) and i sure as hell aint testing em all out only to find it supports an extra screenmode.
Now i know we aren't on the same scale here, but i'd hate to have to choose a build when both have their own good points...

BTW, about the HRP pack beta, i'd like to help out with that. In building the one i released, i've learned the structure of it all and how it works. Hope i can be included

[Parkar]

My plan is to make it (hrp beta) publicly available on these boards. Then anyone who wants to can help out.

[ProAsm]

Parkar go ahead as I've managed to add a "rejectmodel" feature incase we dont get it right.
Doing it this way allows us to have any folder placements we want.
I currently have a small hitch in getting it going but I'll get around it.
Basically if possible we need a Sw.def file that has a line in the beginning of include reject.def or whatever filename you would like to give it.
It has to be the first line as it stores all the rejects, then when the actual MD2's, Textures or whatever we want change thats a bit difficult we can just reject them.

Currently it works quite well with:
rejectmodel "highres/sprites/monsters/4096_evilninja2.md2"


djimd, I'll check out what you are say although I have been over it a zillion times.
What model are you using to replace the Ninja and can you relace the Ninja MD2 witha Sprite ?

[Parkar]

So the only realy big issue right now is overwriting model defines right?

[djimd]

ProAsm - firstly i must say we really appreciate the work that you're putting in with sw.
Using the zipped user.def method swp.exe does show the md2 ninja model - the only models i cannot get swp.exe to show are the punchstick and the light switch - (don't know about the suitcase) - using sw.exe with the zipped user.def these do show up. The reason i mentioned this is because if you do get them to show using this method then your compatibility problem should be solved - all the highres pack would have to do would include a sw.def placed in the root directory with the line " include user.def". A user.def with all the highres would then be included in the highres.zip. Then each mod just needs its own user.def included in its grp or zip.

[ProAsm]

Parkar, yes, at the end of the day this is the problem and once I get the rejects working correctly, this problem will be history.
Having a include reject.def wont harm anything even if its not used at the end, and thats if djimd is correct in what he is saying.

djimd, what happens if you play Rampage Warrior using your idea, does the Ninja get replaced with the correct sprite in the 2nd level.

For a quick test with the GRP in the root folder:
sw.exe -gRampage.grp -map rwtown.map

In my case no matter what I do, even using a zip instead of a grp all I see are the new Ninja's ?

Maybe you have a different Hires layout to us.

In my case:

Sw.def
include highres/textures.def
include user.def
definetint 14 255 110 80 0

Highres/Textures.def
include highres/skybox.def
include highres/switches.def
include highres/fonts.def
include highres/redfonts.def
include highres/sprites.def

definetexture (all the textures)

[djimd]

Hi bud
Yep if i play either:
sw.exe -gRampage.grp -map rwtown.map
or
sw.exe -gRampage.zip -map rwtown.map
or
swp.exe -gRampage.grp -map rwtown.map
or
swp.exe -gRampage.zip -map rwtown.map

with user.def inside user.zip

Then your new custom mod sprites show up.

However, if I then unzip my user.def into the root sw directory then the new ninja .md2 model shows up in all the above cases.

Just to clarify : my sw.def (in root sw directory) =

// Extra additions to the game

include User.def
include highres/fonts.def

definetint 14 255 110 80 0

my user.def =

include highres/skybox.def
include highres/textures.def
include highres/sprites.def

(sprites.def includes monsters,props and switches)

Hope this helps - because the ninja model can only show up if it is defined - if you don't tell the exe to look for a user.def that defines the model then it can't appear.

Just had a look at your defs and because you are defining highres/textures.def in sw.def then yes you will also be defining sprites.def with every game or mod that you play - user.def is the logical solution.

In your case delete "include highres/textures.def" from sw.def and then change the name of your textures.def to user.def and zip this up - place the zip (called user.def) into the root sw directory and run sw with:
swp.exe /guser.zip to show highres ( swp.exe only to show game without highres)

[Parkar]

Wait a sec, would not this work?

The problem with the models is that the first define is used right? Now if I put include reject.def then include user.def you remove models all toghter with rject.def and replace them with user.def since the first will be used. Ohh wait this will kill texture replace ment so its probably better to have a sw.def like this.

include user_reject.def
include user_models.def
<the HRP includes>
include user_textures.def

It would better though if we could replace models and textures in the same def file though. Ugly way of doing it would be includeing a user.def both before the other defs and after effectivly making sure it's defined both first and last.

How would reject solve replaceing models with new models? wouldn't it rejcet the mods defines of that model to?

[hitman71]

please reveal todays countdown conundrum...

borefedspur

ok, its 11 not 9 letters... sue me

[ProAsm]

Firstly djimd, you have a completely non standard installation and that is my whole point here.

The standard can only be set 2 ways and no other way.
1. By JonoF when he releases his 1st version (which he did)
2. When Parkar releases his 1st HRP

At no other time can anyone just change the standard to suit themselves.

Currently the Sw.def has a standard like mine above.
The include User.def was a copy from the Duke standard which Parkar set which is a good idea and it comes last and not first.
Maybe it should come first, thats why yours works but it wont work when a sprite needs to replace an MD2 like in RW.

So if you are 100% sure what you say works, then we must all try it and replicate it and do it so that it works.
Parkar can then build that into his 1st release HRP and that will be the standard for ever and ever amen

My changing the code and adding a Reject is failing badly and I think we need to discount that route at the moment.

It would better though if we could replace models and textures in the same def file though.

Yes this is what I had in mind but as you say it can and will get very messy.
Remember in the beginning with JFDuke3d when we had a Models folder with a Models.def and everything went in there, well that work 100% as modders could get to the stuff, duplicate the models.def in the zip file and set stuff up as they wanted, but as you say it got veru messy hence your new Highres setup which was great for the player and modeller but sucked big time for the TC maker

Anyways we getting some good inputs and will test them out.

[djimd]

ProAsm said:
Firstly djimd, you have a completely non standard installation and that is my whole point here.

The standard can only be set 2 ways and no other way.
1. By JonoF when he releases his 1st version (which he did)
2. When Parkar releases his 1st HRP

At no other time can anyone just change the standard to suit themselves.

Currently the Sw.def has a standard like mine above.
The include User.def was a copy from the Duke standard which Parkar set which is a good idea and it comes last and not first.
Maybe it should come first, thats why yours works but it wont work when a sprite needs to replace an MD2 like in RW.

So if you are 100% sure what you say works, then we must all try it and replicate it and do it so that it works.
Parkar can then build that into his 1st release HRP and that will be the standard for ever and ever amen

My changing the code and adding a Reject is failing badly and I think we need to discount that route at the moment.

Yes this is what I had in mind but as you say it can and will get very messy.
Remember in the beginning with JFDuke3d when we had a Models folder with a Models.def and everything went in there, well that work 100% as modders could get to the stuff, duplicate the models.def in the zip file and set stuff up as they wanted, but as you say it got veru messy hence your new Highres setup which was great for the player and modeller but sucked big time for the TC maker

Anyways we getting some good inputs and will test them out.

The point i am trying to make is that "my" (really parkar's) user.def idea does work and could easily be "standard" - in fact you have already made this route an easy standard by having a user.def included in each of your recently re-vamped mods. It is simple and probably alot less confusing than reject.defs and double defines and undefines - lol now i'm getting confused.

[ProAsm]

Yes ok, and I would prefer to do it with files rather than changing the code as it can get very confused and messy.
I'll to some experiment on what you are saying for the rest of the day and see what I can also come up with.
Your idea of having the include User.def file as the very first file in the Sw.def I think is a big leap forward, we now only need to see what the other issues this would cause if any.

[Parkar]

Just talked to JonoF and the models are suposed to be overridden just like the textures but of unknown resons it doesn't work. He says he can't see any reson for why it doesn't work.

I guess this is what needs to be fixed then and we should be all set.

[ProAsm]

Parkar, yes I agree, we need to fix the problem but that takes time, too much time and could take years.
I'm sure JF as well as Ken have already spent time on this as I know I have and a lot of time too and for the love of money I cannot see why it does not work.
The only thing that could change it is maybe (longshot) if each model has its own def file.
I have sat the last 10 hours messing around trying to get the RejectModel to work correctly and found if it goes in the Sw.def file as an include Reject.def then it does not work... well it does but generates a zillion errors, but if I make it a standalone file and have a special call routine for it in the code:
if (!loaddefinitionsfile("reject.def"))
then it works great although I have other major unrelated issues.
Its a tough one, but as I say, we cannot wait for a code fix on this unless JF or Ken can pull a trick very quickly

[Parkar]

My sugestion is solveing it in the HRP by includeing it twice until its solved. that way the mods will work the same way both before and after its fixed.

[ProAsm]

Yes lets do that and djimd's way works pretty well except in many cases one only needs to get to some particular MD2's and not all of them.
The User_Textures is not needed as textures overwrite each other anyway and they just go in the zip/grp file as a root entry and it works fine.
I feel all we need is something as follows:

include usermods.def
include (all the hrp stuff)
include user.def

the usermods.def can be used to be first at adding MD2's while the user.def can be used for the rest.

Just one thing I noticed which you must be aware of, is that when using Kextract and Kgroup all names are truncated to 8 characters like in DOS.
I came short on this with Rampage Warrior as originally my SwCustom.cfg was called SwpCustom.txt and the game could not find it and when I looked inside the GRP file it was SwpCus~1.txt - just be aware

[Parkar]

I would sugest just using the user.def and simply include it twice since the usermods.def would be obsolute once the model issue is resolved. Only problem I see is that its parsed twice but since its only done when you load the game and its a temporary(more or less) work around I don't see any issues with it. Once its resolved I could just remove the first user.def line and all the old mods should still work. Unless there is something else that needs considering.

[ProAsm]

Using the user.def twice is fine, its just that in some cases it could get huge and everything happens twice where if it were 2 different files the one with the models would normally be fairly small.
I'm not exactly sure how load times would effect slower CPU's and thats basically my only worry, else go for it

[ProAsm]

Well after some heavy testing this end it looks like I may been half wrong all along and it would seem a new MD2 model WILL overwrite an existing one.
The only problem left which is a big one is that a Sprite or character texture will not overwrite a MD2 model.

The only way this can happen is through a reject routine and here I need Ken or JF's help possibly as there is stuff I dont understand in the code.

So it looks like the file will still be the same as discussed but perhaps not calling the user.def twice I dont think.
Or maybe just leave the first one out as I can always do something with SWP if it comes to that

[Parkar]

It works? what have people been doing wrong then? I haven't had the time to get into any serious work or testing any of the HRP's.

[ProAsm]

The test i did was as follows.
I did not have a decent MD2 to use so what I did was modify the Ninja to a very blue color and added all the files to another folder and called it from a include user.def at the end of the sw.def file
This works great in both sw and swp.

The main problem is that 99.9% of TC's out there still use Sprites instead of MD2's and this is where the problem lies as I very much doubt we going to see a TC with new MD2 models in it in a hurry or ever for that matter so it is still very important that we can accomodate Sprite Monsters/Weapons/Pickups/Props or whatever MD2 models we might add to the default game.

So to answer your question, nobody has been doing anything wrong really as there is no MD2 models to overwrite current ones and only Sprites as mentioned above.

So Sprites cannot overwrite MD2's which is the main issue.

[Parkar]

Hmm, ok, just somehow remember people complaining about not being able to replace models with models.

Only way to fix the sprite thing seems to be by adding a reject model/highres texture comand to the define language just like you have been trying. Something like reject model <tilenumber0> <tilenumber1>

[ProAsm]

There is no real way of undefining something.
What I've been doing (trying) is to read in all the required rejects.
Each reject would be a duplicate of the DefineModel line as in:
rejectmodel "highres/sprites/monsters/4096_evilninja2.md2" 3 0
In this case the whetever is in quotes gets stored in a string structure.
So when the actual DefineModels come in like:
definemodel "highres/sprites/monsters/4096_evilninja2.md2" 3 0
It now looks to see if the same quote is in the rejects list and if it is it just performs a return.
This all works great except I have a wierd problem with the reject string structure and cannot solve it.

[ProAsm]

Ok I have solved my problem and the reject option is working very well now.
It only has one dependant and that is that it cannot be an include file and has to be stand alone which will be called by Swp internally and Sw soon hopefully.

The file is simple and for want of a better name - Reject.def
reject "highres/sprites/monsters/4096_evilninja2.md2"
reject "highres/sprites/props/punchstick.md3"

You can have as many rejects as you want as long as they are md2 or md3.

All I gotta figure now is why Swp wont load a MD3.
I'll also continue trying to get the reject file to be an include but I dont think that will work.

[SamSwashbuckler]

Instant Messenger, anybody? :P

[hitman71]

i quite like reading the progress and ongoing headbanging.

[TerminX]

ProAsm said:
Ok I have solved my problem and the reject option is working very well now.
It only has one dependant and that is that it cannot be an include file and has to be stand alone which will be called by Swp internally and Sw soon hopefully.

The file is simple and for want of a better name - Reject.def
reject "highres/sprites/monsters/4096_evilninja2.md2"
reject "highres/sprites/props/punchstick.md3"

You can have as many rejects as you want as long as they are md2 or md3.

All I gotta figure now is why Swp wont load a MD3.
I'll also continue trying to get the reject file to be an include but I dont think that will work.

You do realize the patch to the engine contained here includes things like the "undefmodel" command, right?

[ProAsm]

I thought I had all the patches as the last engine patch was on the 5th June that JF gave us.
Is this yours and if so how does it work etc.
I'll have a look at it tomorrow also.

[ProAsm]

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.

I have however concluded the approach with Swp and it works very well.
Parkar, there is no need for any includes as long as the last line in the sw.def is a include user.def (remember the 8 characters)
Swp now looks in the ZIP or GRP file or in the root folder for that matter for reject.def and if found will use that file as a table and compare all incoming models to it.
The commands can be either rejectmodel or just reject.
For instance to reject the current Ninja, just copy and paste whatever is quotes in the definemodel:
rejectmodel "highres/sprites/monsters/4096_evilninja2.md2"

Attached is a reject.def that can go in the Rampage.grp to demonstrate this or just put it in the sw root folder and permanently reject the Ninja as a test.
Ultimately I would like to reject models by the starting Tile number which I think is what TerminX tried to do and is still the way to go but this way will suffice for the time being.

The lack of reading MD3's has also been fixed in Swp

http://www.unreal.co.za/files/temp/Swp.zip

*** Edit ***
Make sure its SWP Version 1.2 - see in sw.log as I uploaded twice.