Smith

---

Thanx man. I want to be sure to include a lot of the stuff people have added in jk.exe patches, but also maybe include patch gobs like the stuff you're working on as the default "enhanced" JK. i think that would be cool.

especially if they are small in filesize, or if we can think of a way to procedurally do it; eg. patch 1 line in a .JKL file rather than embed a whole copy. that helps us stay away from the whole "dont include game assets" sacred rule. also the sound engine supports mp3 etc. so if we needed to replace sound effects then we could keep the overall smith.exe size down to a minimum.

the reverb environment audio effects im finishing up and the texture upscaling are also things that are on by default but can be disabled to maintain the "true" JK experience in all its 16-bit color glory (or near enough to it lol.. im not going to implement the SW renderer).


gettin rambly, sorry. anyway spill any ideas u got, im always open

---

So question.... I remember that an issue people were having with projects like sith2 was they couldn't figure out how to do the physics code correctly for overlapping sectors. How did you overcome that problem?

---

and yea glitch i was working on an autoexec.cog framework yesterday- normally there will be one embedded in the exe as a default. its intended for system stuff that's always there unless a level or mod overrides it.

an example is every frame autoexec.cog receives a queryenvironment: message and either returns 0 and Smith will determine the audio environment / reverb effects, or you can return 1 and apply your own logic.

i could add (or repurpose.. loading: maybe?) another cog message that allows you do to augments to the JKL file (in memory) before its parsed. some kind of simple API like

loading: jkl = jklGetFileName(); if( compareString(jkl, "03katarn.jkl") ) {   line = jklFindLine("249: battery         battery           1.657500   -0.226070   -0.102091   0.000000   0.000000   0.000000   163   ");   jklRemoveLine(line);   jklInsertLine(line, "249: crate02         crate02           1.657500   -0.226070   -0.102091   0.000000   0.000000   0.000000   163   " }

---

Or better yet, you could try setting either the elevator adjoin or the floor below the elevator as not crossable/walkable by AI. Not sure that would work though, but it's probably worth a try.

Most practical solution I can think of though is modifying that level's startup cog and giving that officer (its thing number could be checked on the JKL) AI Mode flags 0x2000 (AI is disabled) and clearing it on a "sighted" message, so that he wouldn't do anything until the player actually sees him.

Quote:

As far as ideas, if you have any way of getting a hold of Libsa Norec --> That dude has some wicked ideas for some COG verbs that would be AMAZING if implemented.

Strike, I wrote most of my ideas here. I must say I absolutely love what you're doing here. The sound filters and the camera thing in particular are amazing and both things I've always wanted to see, as well as the customizable keyframe markers.

---

Uhm libsa i have a problem

Quote:

* int cog = GetThingLevelCog(int thing, int ID); * int cog = GetSectorLevelCog(int sector, int ID); * int cog = GetSurfaceLevelCog(int surface, int ID); Returns the [ID+1]th cog that references that thing/sector/surface in the current level's JKL. Returns -1 if [ID+1] exceeds the amount of times that thing is referenced in the current level's Cogs. This could be used, for example, to "activate" or "damage" a surface without actually activating/damaging it by sending messages to all that thing/sector/surface level cogs. Alternately... * int dummy = SendMessageToThing(int thing, message, param0, param1, param2, param3); * int dummy = SendMessageToSector(int sector, message, param0, param1, param2, param3); * int dummy = SendMessageToSurface(int surface, message, param0, param1, param2, param3); Same as SendMessageEx(), but would send the message to all cogs that reference that thing/sector/surface. A value could be returned via ReturnEx().

do you want this just to search what is defined in the .jkl?

or

do you want it to be dynamic, and match any symbol (declared at the top of a .cog file) that currently points to the thing/sector/surface in question.. regardless if it was set that way at startup or if a cog assigned it to something new


the second way is actually less code albeit wouldnt execute as fast.. but i feel like its still a more flexible option

---

where would jkSetSaberLightIntensity pull the value from?

only template references i can find for thing light is "light" which is base light 0.2 for player and other values for blaster bolts and explosions.. and "lightintensity" which is default 0.8 which i assume is the fieldlight light value (added to the "light" .. resulting in 1.0).

do you think the lightsaber light should assume the same value as headlight or no.. also, i wonder what happens if you have your lightsaber out and turn on fieldlight at same time.. if toggling fieldlight has no overall effect on lighting then the mystery is solved.



you know what, i should just say screw it and create an additional dynamic light in the center of the lightsaber blade (per frame) and also of the color of the lightsaber. this way the lighting effect actually is affected by swinging saber animations. and heaven forbid if we had shadows implemented to smith at some point.. that would result in koool [censored] effects

---

OK lol ill just play around and see what looks good i guess