Home » MODDING HQ 1.13 » v1.13 Modding, Customising, Editing » v1.13 Modding, Customising, Editing » Changing Tilesets
|
|
| Re: Changing Tilesets[message #237090]
|
Sun, 08 November 2009 17:53  
|
|
| KEN C |
 |
Messages:244
Registered:May 2007
Location: Aberdeen Washington USA |
|
|
Good luck! The people who understand JA2tse seem to think that it is a no brainer. the rest of us are left out in the cold. I have been asking for help for two years now and all I get is cryptic answers and off topic comments that hijack the thread.
If it's so goddamn easy then why is there no published information about how to use it. And why are .stis called files when they are actually folders containing many individual files? To me thats where the problem lies is sorting out the individual pictures inside a .sti.
Report message to a moderator
|
Sergeant 1st Class
|
|
|
|
| Re: Changing Tilesets[message #237093]
|
Sun, 08 November 2009 18:23
|
|
 smeagol |
 |
Messages:2705
Registered:June 2008
Location: Bremen, Germany |
|
|
Totally agree there. If people expect to get good mods, then the necessary knowledge should be shared in a way that people without coding experience get the point. Most of the stuff I did so far is more or less self-taught, but the map editor and the xml editor work quite intuitive, so no big deal there... everything else needed for more indepth modding, however, is really cryptic.
Problems start, when certain things are missing in a tileset. As stated above, I'd really like to see wooden crates in the tropical tileset, walls on rooftop levels, wall decorations (like shop signs for example) in different tile sets...
Working with scripts, tilesets, speech files, etc. is really complicated. Adding quests, NPCs and such is way above my abilities at the moment, and that's unfortunate, as there are quite some things I could imagine to add...
Report message to a moderator
|
|
|
|
|
| Re: Changing Tilesets[message #237095]
|
Sun, 08 November 2009 18:28
|
|
|
|
I have seen animated wall decorations, and animated tiles in scorpions multiplayer mod Fight For Freedom (FFF). Maybe you should try getting a hold of him.
Also, if I am not mistaken he is alos author to the Renegade Republik mod.
Report message to a moderator
|
|
|
|
|
| Re: Changing Tilesets[message #237098]
|
Sun, 08 November 2009 19:02
|
|
| the scorpion |
 |
Messages:1834
Registered:September 2004
Location: CH |
|
|
smeagol
Is there somewhere a tutorial how to {change//edit//add stuff to} a tileset???
Yes. http://www.jaggedalliance.de/ub/tutorials/tileset.shtml
while it's been there since 2002, it's still not wrong to read it now. :animread:
As to your example: i guess there's a redundant slot in TS 34. Ah yes, 88/ 90 or 89/91 are redundant, with some luck you don't get an overflow, so simply use these slots for drum_02.sti or whatever else you want to copy. Then check all maps of the same tileset if the redundant slots have both been used. Keep this in mind if you ever want to work with tilesets, always only use the same object slot if there are redundancies (there were many)
if slot 89/91 flow over, try again using slot 77 and furniture-type crates (like tose grey ones used in tileset 35, i_crates). Slot 77 might be less prone to flowing over. But neither should 88/90 nor 89/91, at least in my experience with most tilesets.
Alternativly, the obvious thing to do is to check out existing mods and see what has been done
There's no better way than that to get all the answers on a silver platter. And what goes beyond the things already done in other mods can't be expected to be documented anywhere, so it has to be aquired by oneself some way or other.
Report message to a moderator
|
Sergeant Major
|
|
|
|
|
|
|
|
| Re: Changing Tilesets[message #237118]
|
Sun, 08 November 2009 21:12
|
|
| the scorpion |
|
Messages:1834
Registered:September 2004
Location: CH |
|
|
truck.sti and furn_6.sti are duplicates in vanilla ja2's TS 34. Wildfire may be a different story in case you were editing widlfire tilesets and didn't mention it.
You can bet that if there was a way to actually *add* new objects to tilesets by adding new slots to the tilesets, it would have been done. Minor stuff may be added to existing tiles by enlarging the corresponding .jsd and .sti files though. But that's another story.
The vast majority of vanilla tilesets have redundant objects, so there's usually quite a lot of room to add things. Also, you can amend an entirely new tileset and use that one. But that requires quite some copy-pasting of data. Some mods like renegade republic have like 70-something tilesets rather than the usual 50 or 60 (UB).
Report message to a moderator
|
Sergeant Major
|
|
|
|
|
|
|
|
| Re: Changing Tilesets[message #237205]
|
Mon, 09 November 2009 16:00
|
|
| the scorpion |
|
Messages:1834
Registered:September 2004
Location: CH |
|
|
black dragon's jsd editor as well as more recent jsd editors basing on black dragons' are available in english IIRC.
IMHO important with jsd editors is the capability to copy-paste objects from one jsd to the other (espeically if you want to add more objects to an existing jsd). Fine tuning will then usually not be necessary, as you have a fine tuned jsd from one file already that just needs to be copied over.
As with wildfire having already used up the redundant slots, one option is always to sacrifice the tiles on drum_02's (or whatever else tile from TS 0) slot, so you don't need to copy any files. This method is both more elegant and less prone to errors than re-introducing a tile that's already in TS 0.
Report message to a moderator
|
Sergeant Major
|
|
|
|
|
|
| Re: Changing Tilesets[message #237216]
|
Mon, 09 November 2009 17:21
|
|
| the scorpion |
|
Messages:1834
Registered:September 2004
Location: CH |
|
|
smeagolthe scorpionAs with wildfire having already used up the redundant slots, one option is always to sacrifice the tiles on drum_02's (or whatever else tile from TS 0) slot, so you don't need to copy any files. This method is both more elegant and less prone to errors than re-introducing a tile that's already in TS 0.
Sorry, I think I don't understand this.
drum_02 are the wooden crates, right?
What I find strange is, that certain tilesets only contain 2 objects (like the red cars for example), but others contain up to 16 objects. Wouldn't it be possible to enhance the size of a tileset with only two objects to contain some more objects (and still contain the original 2 objects)?
That paragraph above isn't really important, so no problem not yet understanding it. Some time working with ja2tse you'll see what i meant. These things are sometimes difficult to explain, especially within language limitations such as the ones i encounter when trying to write coherent english sentences 
drum_01 or drum_02, one of those... one of them is the crates, the other one is the drums. That was just concerning your example.
You're asking the right questions there. Yes it is a bloody waste of slots to have some tiles only contain one or two objects. And Yes these can be enlarged rather easily (copy-paste-merge of jsd and sti) however, there are some hardcoded limits. I'd have to look them up in detail. ja2005 has them externalised so there should be a list in the ja2005 download... bear with me...
uhh, that's a long list...
Bear in mind that ja2005 may have made some changes (especially where they use hundreds of SMITEM slots)
Also, i always had the feeling that there's a second limit, an overall limit for each tileset but as it looks like, the limit is defined for each slot...
[TILETYPE0]
name=TEXTURE1
frames=35
[TILETYPE1]
name=TEXTURE2
frames=35
[TILETYPE2]
name=TEXTURE3
frames=35
[TILETYPE3]
name=TEXTURE4
frames=35
[TILETYPE4]
name=TEXTURE5
frames=35
[TILETYPE5]
name=TEXTURE6
frames=37
[TILETYPE6]
name=TEXTURE7
frames=49
[TILETYPE7]
name=WATER1
frames=50
[TILETYPE8]
name=DEEP WATER
frames=37
[TILETYPE9]
name=FIRSTCLIFFHANG
frames=17
[TILETYPE10]
name=FIRSTCLIFF
frames=17
[TILETYPE11]
name=FIRSTCLIFFSHADOW
frames=17
[TILETYPE12]
name=OSTRUCT1
frames=12
[TILETYPE13]
name=OSTRUCT2
frames=12
[TILETYPE14]
name=OSTRUCT3
frames=12
[TILETYPE15]
name=OSTRUCT4
frames=12
[TILETYPE16]
name=OSTRUCT5
frames=12
[TILETYPE17]
name=OSTRUCT6
frames=12
[TILETYPE18]
name=OSTRUCT7
frames=12
[TILETYPE19]
name=OSTRUCT8
frames=12
[TILETYPE20]
name=OFSTRUCT1
frames=12
[TILETYPE21]
name=OFSTRUCT2
frames=12
[TILETYPE22]
name=PLACEHOLDER1
frames=2
[TILETYPE23]
name=PLACEHOLDER2
frames=2
[TILETYPE24]
name=SHADOW1
frames=12
[TILETYPE25]
name=SHADOW2
frames=12
[TILETYPE26]
name=SHADOW3
frames=12
[TILETYPE27]
name=SHADOW4
frames=12
[TILETYPE28]
name=SHADOW5
frames=12
[TILETYPE29]
name=SHADOW6
frames=12
[TILETYPE30]
name=SHADOW7
frames=12
[TILETYPE31]
name=SHADOW8
frames=12
[TILETYPE32]
name=FSHADOW1
frames=12
[TILETYPE33]
name=FSHADOW2
frames=12
[TILETYPE34]
name=PLACEHOLDER3
frames=2
[TILETYPE35]
name=PLACEHOLDER4
frames=2
[TILETYPE36]
name=WALL1
frames=65
[TILETYPE37]
name=WALL2
frames=65
[TILETYPE38]
name=WALL3
frames=65
[TILETYPE39]
name=WALL4
frames=65
[TILETYPE40]
name=DOOR1
frames=20
[TILETYPE41]
name=DOOR2
frames=20
[TILETYPE42]
name=DOOR3
frames=20
[TILETYPE43]
name=DOOR4
frames=20
[TILETYPE44]
name=DOORSH1
frames=20
[TILETYPE45]
name=DOORSH2
frames=20
[TILETYPE46]
name=DOORSH3
frames=20
[TILETYPE47]
name=DOORSH4
frames=20
[TILETYPE48]
name=SLANTFLATPEICE
frames=2
[TILETYPE49]
name=ANOTHERDEBRIS
frames=10
[TILETYPE50]
name=ROADPIECES
frames=400
[TILETYPE51]
name=WINDOW4
frames=2
[TILETYPE52]
name=DECORATIONS1
frames=10
[TILETYPE53]
name=DECORATIONS2
frames=10
[TILETYPE54]
name=DECORATIONS3
frames=10
[TILETYPE55]
name=DECORATIONS4
frames=10
[TILETYPE56]
name=WALLDECAL1
frames=10
[TILETYPE57]
name=WALLDECAL2
frames=10
[TILETYPE58]
name=WALLDECAL3
frames=10
[TILETYPE59]
name=WALLDECAL4
frames=10
[TILETYPE60]
name=FLOOR1
frames=8
[TILETYPE61]
name=FLOOR2
frames=8
[TILETYPE62]
name=FLOOR3
frames=8
[TILETYPE63]
name=FLOOR4
frames=8
[TILETYPE64]
name=ROOF1
frames=14
[TILETYPE65]
name=ROOF2
frames=14
[TILETYPE66]
name=ROOF3
frames=14
[TILETYPE67]
name=ROOF4
frames=14
[TILETYPE68]
name=SROOF1
frames=20
[TILETYPE69]
name=SROOF2
frames=20
[TILETYPE70]
name=ONROOF1
frames=12
[TILETYPE71]
name=ONROOF2
frames=12
[TILETYPE72]
name=MOCKF1
frames=1
[TILETYPE73]
name=ISTRUCT1
frames=24
[TILETYPE74]
name=ISTRUCT2
frames=24
[TILETYPE75]
name=ISTRUCT3
frames=24
[TILETYPE76]
name=ISTRUCT4
frames=24
[TILETYPE77]
name=FIRSTCISTRCUT
frames=24
[TILETYPE78]
name=FIRSTROAD
frames=35
[TILETYPE79]
name=ROCKS
frames=10
[TILETYPE80]
name=WOOD
frames=10
[TILETYPE81]
name=WEEDS
frames=10
[TILETYPE82]
name=GRASS
frames=10
[TILETYPE83]
name=SAND
frames=10
[TILETYPE84]
name=MISC
frames=10
[TILETYPE85]
name=ANIOSTRUCT
frames=20
[TILETYPE86]
name=FENCESTRUCT
frames=22
[TILETYPE87]
name=FENCESHADOW
frames=22
[TILETYPE88]
name=FIRSTVEHICLE
frames=12
[TILETYPE89]
name=SECONDVEHICLE
frames=12
[TILETYPE90]
name=FIRSTVEHICLESHADOW
frames=12
[TILETYPE91]
name=SECONDVEHICLESHADOW
frames=12
[TILETYPE92]
name=MISC2
frames=10
[TILETYPE93]
name=FIRSTDEBRISSTRUCT
frames=10
[TILETYPE94]
name=SECONDDEBRISSTRUCT
frames=10
[TILETYPE95]
name=FIRSTDEBRISSTRUCTSHADOW
frames=10
[TILETYPE96]
name=SECONDDEBRISSTRUCTSHADOW
frames=10
[TILETYPE97]
name=NINTHOSTRUCT
frames=12
[TILETYPE98]
name=TENTHOSTRUCT
frames=12
[TILETYPE99]
name=NINTHOSTRUCTSHADOW
frames=12
[TILETYPE100]
name=TENTHOSTRUCTSHADOW
frames=12
[TILETYPE101]
name=FIRSTEXPLODEDEBRIS
frames=40
[TILETYPE102]
name=SECONDEXPLODEDEBRIS
frames=40
[TILETYPE103]
name=FIRSTLARGEEXPLODEDEBRIS
frames=10
[TILETYPE104]
name=SECONDLARGEEXPLODEDEBRIS
frames=10
[TILETYPE105]
name=FIRSTLARGEEXPLODEDEBRISSHADOW
frames=10
[TILETYPE106]
name=SECONDLARGEEXPLODEDEBRISSHADOW
frames=10
[TILETYPE107]
name=FIFTHISTRUCT
frames=24
[TILETYPE108]
name=SIXTHISTRUCT
frames=24
[TILETYPE109]
name=SEVENTHISTRUCT
frames=24
[TILETYPE110]
name=EIGHTISTRUCT
frames=24
[TILETYPE111]
name=FIRSTHIGHROOF
frames=15
[TILETYPE112]
name=SECONDHIGHROOF
frames=15
[TILETYPE113]
name=WALLDECAL5
frames=10
[TILETYPE114]
name=WALLDECAL6
frames=10
[TILETYPE115]
name=WALLDECAL7
frames=10
[TILETYPE116]
name=WALLDECAL8
frames=10
[TILETYPE117]
name=HUMANBLOOD
frames=16
[TILETYPE118]
name=CREATUREBLOOD
frames=16
[TILETYPE119]
name=FIRSTSWITCHES
frames=21
[TILETYPE120]
name=REVEALEDSLANTROOF
frames=8
[TILETYPE121]
name=1stREVEALEDHIGHROOF
frames=11
[TILETYPE122]
name=2ndREVEALEDHIGHROOF
frames=11
[TILETYPE123]
name=GUNS
frames=60
[TILETYPE124]
name=ITEMS
frames=149
[TILETYPE125]
name=ITEMS2
frames=45
[TILETYPE126]
name=GLASSSHATTER
frames=20
[TILETYPE127]
name=ITEMS3
frames=16
[TILETYPE128]
name=BODYBLOW
frames=15
[TILETYPE129]
name=EXITTEXTURE
frames=35
[TILETYPE130]
name=FOOTPRINTS
frames=80
[TILETYPE131]
name=POINTERS
frames=24
[TILETYPE132]
name=POINTERS2
frames=8
[TILETYPE133]
name=POINTERS3
frames=3
[TILETYPE134]
name=GOODRUN
frames=11
[TILETYPE135]
name=GOODWALK
frames=11
[TILETYPE136]
name=GOODSWAT
frames=11
[TILETYPE137]
name=GOODSCOOT
frames=11
[TILETYPE138]
name=CONFIRMMOVE
frames=11
[TILETYPE139]
name=VEHICLEMOVE
frames=10
[TILETYPE140]
name=ACTIONTWO
frames=11
[TILETYPE141]
name=BADMARKER
frames=11
[TILETYPE142]
name=GRING
frames=10
[TILETYPE143]
name=ROTATINGKEY
frames=8
[TILETYPE144]
name=SELRING
frames=10
[TILETYPE145]
name=SPECIAL
frames=6
[TILETYPE146]
name=BULLET
frames=2
[TILETYPE147]
name=MISS1
frames=5
[TILETYPE148]
name=MISS2
frames=5
[TILETYPE149]
name=MISS3
frames=14
[TILETYPE150]
name=WIREFRAME
frames=15
[TILETYPE151]
name=ITEMS4
frames=12
[TILETYPE152]
name=ITEMS5
frames=12
[TILETYPE153]
name=ITEMS6
frames=12
[TILETYPE154]
name=ITEMS7
frames=12
[TILETYPE155]
name=ITEMS8
frames=12
[TILETYPE156]
name=ITEMS9
frames=12
[TILETYPE157]
name=ITEMS10
frames=12
[TILETYPE158]
name=ITEMS11
frames=12
[TILETYPE159]
name=ITEMS12
frames=12
[TILETYPE160]
name=ITEMS13
frames=12
[TILETYPE161]
name=ITEMS14
frames=12
[TILETYPE162]
name=ITEMS15
frames=12
[TILETYPE163]
name=ITEMS16
frames=12
[TILETYPE164]
name=ITEMS17
frames=12
[TILETYPE165]
name=ITEMS18
frames=12
[TILETYPE166]
name=ITEMS19
frames=12
[TILETYPE167]
name=ITEMS20
frames=12
[TILETYPE168]
name=ITEMS21
frames=12
[TILETYPE169]
name=ITEMS22
frames=12
[TILETYPE170]
name=ITEMS23
frames=12
[TILETYPE171]
name=ITEMS24
frames=12
[TILETYPE172]
name=ITEMS25
frames=12
[TILETYPE173]
name=ITEMS26
frames=12
[TILETYPE174]
name=ITEMS27
frames=12
[TILETYPE175]
name=ITEMS28
frames=12
[TILETYPE176]
name=ITEMS29
frames=12
[TILETYPE177]
name=ITEMS30
frames=12
[TILETYPE178]
name=ITEMS31
frames=12
[TILETYPE179]
name=ITEMS32
frames=12
[TILETYPE180]
name=ITEMS33
frames=12
[TILETYPE181]
name=ITEMS34
frames=12
[TILETYPE182]
name=ITEMS35
frames=12
[TILETYPE183]
name=ITEMS36
frames=12
[TILETYPE184]
name=ITEMS37
frames=12
[TILETYPE185]
name=ITEMS38
frames=12
[TILETYPE186]
name=ITEMS39
frames=12
[TILETYPE187]
name=ITEMS40
frames=12
[TILETYPE188]
name=ITEMS41
frames=12
[TILETYPE189]
name=ITEMS42
frames=12
[TILETYPE190]
name=ITEMS43
frames=12
[TILETYPE191]
name=ITEMS44
frames=12
[TILETYPE192]
name=ITEMS45
frames=12
[TILETYPE193]
name=ITEMS46
frames=12
[TILETYPE194]
name=ITEMS47
frames=12
[TILETYPE195]
name=ITEMS48
frames=12
[TILETYPE196]
name=ITEMS49
frames=12
[TILETYPE197]
name=ITEMS50
frames=12
[TILETYPE198]
name=ITEMS51
frames=12
[TILETYPE199]
name=ITEMS52
frames=12
[TILETYPE200]
name=ITEMS53
frames=12
[TILETYPE201]
name=ITEMS54
frames=12
[TILETYPE202]
name=ITEMS55
frames=12
[TILETYPE203]
name=ITEMS56
frames=12
[TILETYPE204]
name=ITEMS57
frames=12
[TILETYPE205]
name=ITEMS58
frames=12
[TILETYPE206]
name=ITEMS59
frames=12
[TILETYPE207]
name=ITEMS60
frames=12
[TILETYPE208]
name=ITEMS61
frames=12
[TILETYPE209]
name=ITEMS62
frames=12
[TILETYPE210]
name=ITEMS63
frames=12
So if you look at slot 88 or 89, there should be, by default, space for 12 objects, so you could add 10 more objects to orange trucks without an overflow. Of course you can easily guess that externalizing this limit as in ja2005 means you can stuff seemingly unlimited amounts of items in one tileset, however, as they have to be in the same .jsd and the same .sti, there are limitations of jsd type and palette colours.
Report message to a moderator
|
Sergeant Major
|
|
|
|
|
|
|
|
| Re: Changing Tilesets[message #237226]
|
Mon, 09 November 2009 19:43
|
|
| the scorpion |
|
Messages:1834
Registered:September 2004
Location: CH |
|
|
if you look at existing "t" folders in the .slf's, they contain smaller copies of the tiles and are used to generate radarmaps for example. If you plan to update radarmaps as well, you better copy the smaller files with identical name as your respective sti into the "t" folder, otherwise, you'll get some funky-lookin objects on the radarmaps.
Ah, maybe not only radarmaps... maybe some overview functions or other stuff also use these files... but they're not strictly needed, e.g. the game won't crash if they're missing.
The editor tends to be a good indicator of the full game. Normally, what you see there is what you get in the game, too.
about your last question: ja2set.dat, tilesets, maps (if you made any changes), radarmaps (if you want to/ made changes) but i guess you already figured that by now 
small hint: 1.13 no longer explicitly mentions the lack of a specific tile. Nowadays you get a generic assertion failure message where in the past, the game would have told you what tile is missing (upon crashing). So if you get a generic assertion failure message when trying to load a map, there might be a tile missing or a similar error.
Report message to a moderator
|
Sergeant Major
|
|
|
|
| Re: Changing Tilesets[message #237227]
|
Mon, 09 November 2009 19:49
|
|
| smeagol |
|
Messages:2705
Registered:June 2008
Location: Bremen, Germany |
|
|
the scorpionif you look at existing "t" folders in the .slf's, they contain smaller copies of the tiles and are used to generate radarmaps for example. If you plan to update radarmaps as well, you better copy the smaller files with identical name as your respective sti into the "t" folder, otherwise, you'll get some funky-lookin objects on the radarmaps.
Yes, makes sense... haven't thought about the radarmaps.
Quote:about your last question: ja2set.dat, tilesets, maps (if you made any changes), radarmaps (if you want to/ made changes) but i guess you already figured that by now
yeah, just wanted to make sure I didn't miss any obscure file. ^^
Quote:small hint: 1.13 no longer explicitly mentions the lack of a specific tile. Nowadays you get a generic assertion failure message where in the past, the game would have told you what tile is missing (upon crashing). So if you get a generic assertion failure message when trying to load a map, there might be a tile missing or a similar error.
Okay, guess that's what crashes the demo tileset then.
What exactly is the name of that JSD editor you mentioned earlier?
Report message to a moderator
|
|
|
|
|
|
|
|
|
|
|
| Re: Changing Tilesets[message #238975]
|
Sun, 29 November 2009 15:52
|
|
| the scorpion |
|
Messages:1834
Registered:September 2004
Location: CH |
|
|
BirdFluSome of you may have noticed the file "Ja2Set.dat.xml" that is created in you user profile directory and wondered what can be done with it. Well, not much, until now. While it was just a different representation of the file ja2set.dat before, with the following files
ja2v113_TST.7z - 7.4 Mb
MapEditor_TST.7z - 8.7 Mb
this file is used to fill the internal datastructures. As long as the XML file exists, it is used instead of the DAT file. Otherwise the DAT file is read and used to recreate the XML file, which will be used on next game start again.
If i understand this right, this may just speed up the process of managing and integrating large custom tilesets from one mod to another. Back when we absorbed UC's tilesets into RR, that would have been very handy just to copy-paste a part of an xml rather than try to copy parts of ja2set.dat using ja2tse.
I hope somebody can give this due testing as i'm currently sticking with an ancient editor version
BirdFlu
So, either the XML file has to consider these restrictions or the restrictions itself should be relaxed.
there's certainly a few restrictions that definitely should be relaxed. If you refer to my above posting of the hardcoded number of possible objects per tile slot and their externalisation in ja2005, that's the prime example. But this may be slightly beyond the scope of your xml, i don't know.
(on a related note, ja2005 also removed the tile-tilesets hardcode so that an object in tileset 20 for example could be referenced from tileset 2 (for example) which meant no need to duplicate tiles all over the place, no need to extract existing tiles to re-use them etc.
Maybe you can assess such an idea also within the scope and framework of what you've already achieved with ja2.set.xml
So i could use the currently generated file and then edit it and when i use it with your exe/ editor, the changes would apply... very, very useful stuff here if i understand that correctly :ok:
*edit*
My download of your exe didn't work. It should have been a few megs (4.7 or so?) but it only downloaded a few kilobytes. Will try again later, hopefully it works for others
[Updated on: Sun, 29 November 2009 16:37] by Moderator Report message to a moderator
|
Sergeant Major
|
|
|
|
|
|
| Re: Changing Tilesets[message #238979]
|
Sun, 29 November 2009 16:47
|
|
| KEN C |
|
Messages:244
Registered:May 2007
Location: Aberdeen Washington USA |
|
|
Birdflu, are you saying that I can assemble a data\tileset of my own and and your ja2set.dat.xml will ust it without requiring a set.dat?
your download site is a pain in the butt. maybe try esnips or mediafire?
[Updated on: Sun, 29 November 2009 16:50] by Moderator Report message to a moderator
|
Sergeant 1st Class
|
|
|
|
|
|
| Re: Changing Tilesets[message #249543]
|
Sat, 17 April 2010 12:34
|
|
| BirdFlu |
 |
Messages:438
Registered:September 2007
Location: Lampukistan |
|
|
Here is a new version of the game + editor.
What it does is:
1) reads the tilesets definition from Ja2Set.dat.xml
2) reads structures from XML files (previously JSD)
3) supports 24/32-bit PNG images for BigItems
4) reads strings from XML files
1) reading the tileset definition from an XML file is disabled by default. To activate it you have to set USE_XML_TILESETS to true in ja2.ini. The XML file is created automatically when it doesn't exist.
2) when you set USE_XML_STRUCTURES to true in ja2.ini, the game tries to load filename.xml instead filename.jsd. One restriction is that sometimes the game looks for the existence of JSD file vefore loading it. So, if you create a new XML structure, it may not work unless you also create a (emtpy) jsd file too. To convert the existing JSD files to XML files you need the ja2export.exe program, that is also in the file you just downloaded.
3) BigItems are separate STI images, MediumItems are packed into multiimage STI files. When you set USE_PNG_ITEM_IMAGES to true in ja2.ini you will be able to use PNG files. MediumItems are then separated, just like the BigItems and they have to be in the directory "Interface\". That is, items from mdguns.sti go into "Interface\mdguns\*.png", from mdp1items.sti into "Interface\mdp1items\*.png" etc. MediumItems have to be paletted 8bpp images.
BigItems can be 8bpp or 24bpp or 32bpp PNG images and have to be storen in "BigItems\*.png". To convert the sti files to png files you can/have to use the ja2export.exe program.
4) Many dialogue lines or other strings in the game are stored in EDT files or directly in the code. You can export and use these strings by setting USE_XML_STRINGS to true in ja2.ini. With this option set, the XML files will be read but not written. To create the XML files you also have to set EXPORT_STRINGS to true in ja2.ini. For now only the strings on the AIM website are actually used in the game, although many more are written into the XML files.
Ja2export.exe is a command line proram, so not everyone will exactly like it, but you can create a batch file that will make the life a little bit easier for you. Lets say you put "ja2export.exe" into the same directory as "ja2.exe". Then you create in that directory a new text file and name it "ja2export.bat".
In this file you write
If you double-click on the ja2export.bat file a console will pop up and close immidiately. To make it stay you need to add this to the batch file
Now the simple call of the program doesn't do anything besides printing the help/usage message. I hope that the help messsages are understandable, so i will not explain everything in detail. There are four commands that the program understands, STI, SLF, PNG and HELP. You can print the help messages for these commands by adding the follwing to ja2export.bat (or just enter it in the console now that it is open)
cmd /k ja2export.exe help sti
cmd /k ja2export.exe help jsd
cmd /k ja2export.exe help slf
- or-
ja2export.exe help sti
ja2export.exe help jsd
ja2export.exe help slf
Here is an example how to convert the jsd files in Tilesets.slf
ja2export.exe jsd -lib Data\Tilesets.slf *\*.jsd -create_dst output_xml\.
Here is an example jow to convert the sti file BigItems to png files
// paletted 8bpp images
ja2export.exe sti -onepng Data\BigItems\*.sti Data\BigItems\.
// 32bpp rgba images
ja2export.exe sti -onepng -rgba Data\BigItems\*.sti Data\BigItems\.
EDIT: btw, this exe is based on the most recent version from the MP/Developer branch. In order to start it, you will need a couple of extra files. You can get them from here : https://81.169.133.124/source/ja2/branches/Wanne/JA2%201.13%20MP/GameDir/, or just check out the latest SVN revision of the MP branch.
EDIT2: here a the necessary files in one download http://www.mediafire.com/file/gg4xyzejntt/ja2_jsd_GameDir.7z
[Updated on: Sat, 17 April 2010 15:29] by Moderator Report message to a moderator
|
|
|
|
|
|
|
|
|
|
|
| Re: Changing Tilesets[message #263487]
|
Fri, 24 September 2010 16:03
|
|
| smeagol |
|
Messages:2705
Registered:June 2008
Location: Bremen, Germany |
|
|
A new idea how to maybe make tilesets more versatile:
I don't how difficult it would be, or if it would be more work than one big tileset... anyways... my idea is the following:
Maps load one tileset when they are entered, the one defined for the specific map in the map editor. This of course means, that only objects in that specific tileset will ever show up in a given map. For example: A tileset for a map (like the tileset used for Drassen Airport) has the wirefence as the only available fence. But, due to big maps, it is entirely possible, to also put a small farm in the map. This of course would need a different fence...
Solution:
Instead of only having one tileset at a given time, have two different ones.
So, in the map editor you would basically set two different tilesets the map can use (which would increase the number of available objects by at least 50% for any given map).
This of course also would require the game to know the data it has to load when a sector is entered.
Don't know if this is possible at all or if it would be easier to just make one big tileset with everything in it. Anyways... if the community wants to see big maps in the future, something has to be done about tilesets. ATM it is basically just a waste of time to even try to build a good big map, because the tileset limitations still stink.
Report message to a moderator
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Re: Changing Tilesets[message #268881]
|
Fri, 24 December 2010 03:09
|
|
| Hawkeye |
|
Messages:2416
Registered:October 2005
Location: Australia |
|
|
Damn, I wish Scorpion was still here.
Things are starting to sink in a bit better with me, but it makes sense to have things confirmed. My biggest worry is hitting the limits of how many of these the game can handle, and I've heard that creepy term 'overflow' a bit. Vengeance however seems to have a fair bit of room to work in, so hopefully things won't come to that. At the moment the intention is to just add a few new token props and see how it goes. I was hoping you'd be able to clear up some of the terminology you were using with Scorpion on here previously Smeagol, surely someone out there knows more?
So far I have managed to add a new test vehicle in game, with correct working collision, this is new test art (so ignore dodgy perspective, art style, non shadows etc. of the bright coloured cars) in an extra frame of an existing Sti, there was plenty of room in the palette, so came out quite nice. The JSD shape part has probably been the biggest hurdle, but hopefully one that's now overcome if not 100% understood.
The whole thing's been very demanding, but I've been taking notes as I go along so will post something up when I'm feeling more confident.
Report message to a moderator
|
|
|
|
|
|
|
| Re: Changing Tilesets[message #353591 is a reply to message #353589]
|
Sun, 27 May 2018 13:23
|
|
| townltu |
|
Messages:384
Registered:December 2017
Location: here |
|
|
Thanks for remembering me what info i was searching for, a couple of days ago,
and last not least pointing out where to find it! ;)
(i literally must have already seen the german tut a few times, trying to understand it,
but that was a looong time ago and before the contact with 3D stuff)
Some comments & questions
The 2 different .jss files in \tilesets(each in 2 instances)contain only plain text and eols,
i guess they not used at all and only remnants which survived the cleanup because:
The .jss files appear to relate to sti files, based on their content:
R-KEY.sti contains 8 pics of a key which are most likely intended to represent a rotating key,
so the text in R-KEY.jss supports the assumption. (flags animated; reference to 8 frames)
and the question arises where is the rotaing key in game,
respectively has anybody tried to place R-Key.sti on a map and what is the result in game/editor,
either with correcct r-key.jss residing in tilesets.slf,
and 2 copies of r-key.jss with changed values or simply empty, placed into \tilesets\0 and ~\0\0?
Cliff.jss has entries which appear to mofify offsets for pics in cliff.sti,
but i could not see any differenes in screenshots of grumm cliffs
although one instance used a cliff.jss that has most values drastically changed.
However, some thoughts on "can have only 1 type of fence on a specific map" limitation.
It probably refers to: "can only have one terrain type on a map that allows interaction with item that has wirecutters flag
and transforms into smth else than rubble"
(there is also physical damage from explosion ?etc? but i guess thats another thing as many terrain tiles can be desrtroyed)
If .sti is just a pic with no impact on terrain/structure,
we could fill all plain_ground .sti files of a sector with pics of different fences,
but the new fences should be no obtacle at all as long as the related .jsd files stay untouched.
If the assumption is correct, the 1Fence limitation is either related to the .jsd files,
i which case its a mattter of adjusting jsd and/or perhaps the "environment" of the .jsd for the 2nd fence
or buried in the .exe, e.g. cant handle more than one terrain element related to wirecutters,
in which case the question arises whether somebody already took a look at that part of the code to overcome the limitation?
Report message to a moderator
|
Master Sergeant
|
|
|
|
|
|
Goto Forum:
Current Time: Sat Apr 20 04:14:10 GMT+3 2024
Total time taken to generate the page: 0.02552 seconds
|
Blog
Search
Help
Members
Register
Login
Home
