Home » MODDING HQ 1.13 » v1.13 Modding, Customising, Editing » v1.13 Modding, Customising, Editing » Changing Tilesets
Re: Changing Tilesets[message #353641 is a reply to message #353591]
||Wed, 30 May 2018 02:52 |
||townltu wrote on Sun, 27 May 2018 20:23
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?
I never investigated further with JSS files, and figured it would be more ancillary data for certain actions and seem to recall another modder mentioning something on thos lines a long time ago. I've never needed to use a key anim.
Cliffs can be a royal pain to edit effectively and something I avoid like the plague in Vengeance, I'm not sure if this is a bug that was always evident in Vengeance or the cliffs have always been a tricky tile to handle. I note masking/transparencies can break in some cliff tiles dependent on placement, perhaps those offset or jss values combat this? My Nvidia card also seems to treat JA2 overlays and masks with suspicion of late and I'm getting stray bright green pixels on a number of tiles (mostly when changing from roof to ground levels)that I haven't been able to rectify, though I believe this is an issue with the card or driver rather than JA's engine.
As far as fences, again I never investigated further but the one 'fence' per tileset has always been a limit. I don't know if any coder has looked to see if this could be changed. One thing to note though is not all fences need to have interaction as such, and not all fences can be cut with pliers such as the lower stone structures in Chitzena or the black iron fences at Meduna's arena so there may be some other code going on.
On a side note you can of course replace most tiles with any kind of graphics in game, they just might not act as they should if they are sitting in a slot intended for a different use. For example I was experimenting with larger floating signage tiles that were in another part of the tileset other than room decals but because of this they were not reacting when wall sections were exploded behind them, also Vengeance's large crater tiles are not in debris but seem to work fine apart from lighting due to how they have not been chopped up into 20x40 tiles. Kind of expected, but this also means there maybe some room to expand your tileset in other slots other than what they were intended for, so 1st and 2nd vehicles don't have to have vehicle graphics.
Re: Changing Tilesets[message #353652 is a reply to message #353641]
||Thu, 31 May 2018 19:47 |
||Hawkeye wrote on Wed, 30 May 2018 02:52
...seem to recall another modder mentioning something on thos lines a long time ago. I've never needed to use a key anim.
That was probably CNC_gun`s message 10y ago,
according to it .jss is no obsolete remnant but the script which is allowed to kick in if jsd file is type 1 (or so;)
one of two ways to create a new animation, the rotating key was only the exapmple.
Funnily no mod appears to have used the jss option for new animated terrain stuff on maps,
although i know(also from myself;) that modders love to add some eyecandy.
pls note my above mentioned r-cliff.jss tests were done in a running campaign,
perhaps new game provides different result.
Fences: "... has always been a limit" is not an acceptable reason. ;)
If its a hardcoded limit(still some doubt on that;), either change the code
or use "simulates desired stuff" workaround by assigning data that is accepted by code.
e.g. cliff.jss appears to allow .sti pics to cover neighbouring tiles,
if this is true and also valid for related .jsd structure
(e.g. open wing of w-door1 appears to have no structure in jsd, so blocking function of open door must be stored elsewhere)
we could use a merely visual fence which does not block passage
and create an invisible terrain element adjacent to fence,
with fence like .jsd structure shifted to the tile on which the visual fence is placed.
Current Time: Wed Oct 24 03:54:50 EEST 2018
Total time taken to generate the page: 0.01100 seconds