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 http://forums.3drealms.com/ubbthreads/images/graemlins/smile.gif
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 http://forums.3drealms.com/ubbthreads/images/graemlins/wink.gif


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. http://forums.3drealms.com/ubbthreads/images/graemlins/frown.gif

[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 http://forums.3drealms.com/ubbthreads/images/graemlins/wink.gif) - /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 http://forums.3drealms.com/ubbthreads/images/graemlins/smile.gif - 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 http://forums.3drealms.com/ubbthreads/images/graemlins/smile.gif

[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"
http://forums.3drealms.com/ubbthreads/images/graemlins/wink.gif

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. http://forums.3drealms.com/ubbthreads/images/graemlins/smile.gif
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. http://forums.3drealms.com/ubbthreads/images/graemlins/smile.gif

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 http://forums.3drealms.com/ubbthreads/images/graemlins/smile.gif

[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 http://forums.3drealms.com/ubbthreads/images/graemlins/smile.gif

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 http://forums.3drealms.com/ubbthreads/images/graemlins/smile.gif

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 http://forums.3drealms.com/ubbthreads/images/graemlins/smile.gif

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 http://forums.3drealms.com/ubbthreads/images/graemlins/smile.gif

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. http://forums.3drealms.com/ubbthreads/images/graemlins/doh.gif

[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 http://forums.3drealms.com/ubbthreads/images/graemlins/smile.gif

[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 http://forums.3drealms.com/ubbthreads/images/graemlins/smile.gif

[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 http://forums.3drealms.com/ubbthreads/images/graemlins/smile.gif

[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 http://forums.3drealms.com/ubbthreads/images/graemlins/smile.gif

[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 (http://eduke32.com/stuff/bdiff) 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) http://forums.3drealms.com/ubbthreads/images/graemlins/smile.gif
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.

[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 http://forums.3drealms.com/ubbthreads/images/graemlins/smile.gif

[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 http://forums.3drealms.com/ubbthreads/images/graemlins/doh.gif
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 http://forums.3drealms.com/ubbthreads/images/graemlins/wink.gif

[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 http://forums.3drealms.com/ubbthreads/images/graemlins/wink.gif


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 (http://eduke32.com/stuff/bdiff) 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 http://forums.3drealms.com/ubbthreads/images/graemlins/smile.gif

*** 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 http://forums.3drealms.com/ubbthreads/images/graemlins/wink.gif

[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 http://forums.3drealms.com/ubbthreads/images/graemlins/wink.gif



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. http://forums.3drealms.com/ubbthreads/images/graemlins/tongue.gif

[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' http://forums.3drealms.com/ubbthreads/images/graemlins/smile.gif
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. http://forums.3drealms.com/ubbthreads/images/graemlins/tongue.gif

[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 http://forums.3drealms.com/ubbthreads/images/graemlins/smile.gif

*** 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 http://forums.3drealms.com/ubbthreads/images/graemlins/grin.gif
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 http://forums.3drealms.com/ubbthreads/images/graemlins/wink.gif

[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 http://forums.3drealms.com/ubbthreads/images/graemlins/grin.gif
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 http://forums.3drealms.com/ubbthreads/images/graemlins/wink.gif


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 http://forums.3drealms.com/ubbthreads/images/graemlins/smile.gif
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.