Apples and Peaches: Obsttorte's Mapping and Scripting Thread

[Wellingtoncrab]

On 3/17/2013 at 10:57 AM, Obsttorte said:

How to create a diary/note book

 

There once was the question on this forum, if people like taking notes during the game. The answers varied, but there where some who said that they don't like this, as they are playing in the dark for example.

 

The best solution to this problem seem to have some sort of diary that the player can carry around, and in which notes are automatically added once a certain condition is fulfilled.

 

Hey Obsttorte, 

Thanks again for posting these scripts on here as they cover a lot of features I want to incorporate into my map! I am trying to add a log book which this diary script seems set to perfectly address. I know you wrote the script a long while ago but I am running into an issue where my log book isn't able to contain more than 126 characters - at that point it seems to stop accepting any additional text. This doesn't seem to matter if the source feeding the log is a single long gui_message or multiple smaller ones - once it hits this limit it stops. I have gone through the configuration quite a few times and it seems like I have it setup like you described here and on the wiki page but haven't been able to figure this one out. Again the script seems to work perfectly up until this character limit is hit.

So far I don't seem cut out for much more than the most basic of scripting, but I don't really see an issue with the script itself. I did find reference to a "127 char size limit on script strings." within the TDM script reference under "setGuiStringFromKey" but not sure if that is actually related. I does seem like (in my amateur interpretation) the diary script is appending the new text onto the same "pageX_body <text to go here>" spawnarg line on the diary entity by capturing the content into a single string variable named "thisText", and that if there is indeed a limit to size of a single string variable than that limit would be reached eventually.

Any ideas or insight you may have would be greatly appreciated!

[Obsttorte]

Well, I guess the amount of data storage available per spawnarg is limited, so to take the possibility of more text into account the text would need to be split into several peaces. Will take a look and see if I can modify the script accordingly.

[duzenko]

43 minutes ago, Obsttorte said:

Well, I guess the amount of data storage available per spawnarg is limited, so to take the possibility of more text into account the text would need to be split into several peaces. Will take a look and see if I can modify the script accordingly.

https://bugs.thedarkmod.com/view.php?id=5236

[RedNoodles]

Hi, I've been playing around with your halloween sandbox (helloween.pk4) and I wanted to say the lantern looks awesome. I'd love to see this in a horror mission.

do you know if theres a way to separate it from the sword?

Ive been experimenting with the def files and haven't had much luck.

first thing I did was go into the tdm_player_thief def file and add a new weapon def (there are 12 weapon slots, but TDM only uses 10)

Quote

"def_weapon11"                  "atdm:weapon_lamp"

then I duplicated the default tdm_weapon_shortsword def from TDM and renamed it tdm_weapon_lamp. I compared it to your shortsword def and copied some of the references while giving the functions new names. At this point I could start up darkradiant, create this new lamp entity, load the map, pick it up and equip it alongside the sword.

I then tried to repeat this process with your shortsword script file (which the lamp def file is supposed to point to) after including it in tdm_custom_scripts

TDM doesn't like this new script file for some reason. it crashes on start up citing errors in the weapon_lantern::Idle() function

Quote

$playerlamp_light.On();
    $playerlamp_haze.show();

Quote

$playerlamp_light.Off();
    $playerlamp_haze.hide();

Error: tdm_weapon_lantern.script, line 90: '.' is not a name

I'm stuck. any idea what could be causing this?

[Obsttorte]

The error message basically tells you what's going on. In line 90 of your script whatever is standing in front of the '.' cannot be interpreted by the scripting engine. So either the naming is wrong or something else got messed up during your renaming journey. Note that the setup was intented as a proof of concept only, not as a fundament to build upon and that it's been ages when I hacked it together. I cannot remember any single step of what I've done back then.

[Frost_Salamander]

On 1/4/2013 at 10:30 PM, Obsttorte said:

I just experienced some very strange lightening behaviour on the map I'm currently working on.

 

To make it short, if I open a door several torchlights start casting through worldspawn brushes, although they all cast shadows and are in the level just below me, which is seperated from the room I am in via several visportals, so they just shine trough the floor.

 

Indeed the area were the torches are in is not even rendered when opening the door, as all the visportals leading to that area are closed. I reduced the light_radius on them what decreases the effect, but still it can be seen and it looks really weird.

 

Any suggestions what could cause this behavior? Thanks in advice.

Hey @Obsttorte I was just reading through this thread and saw this post you made about lights (that cast shadows) shining through brushwork.  I saw this behaviour as well with candles, and was wondering if you ever found out why it happened?  I know this post is ancient, but thought I was ask anyways

EDIT: I read several pages after the post, and it didn't look like you found an answer (or at least didn't post about it if you did).

Edited March 29, 2021 by Frost_Salamander

[OGDA]

@Frost_Salamander

I had a problem like that in "A Night Of Loot" where the candles at the stairs to the second floor where shining up into the attic, despite several brushes and visportals being in the way. In that case it turned out, that a specific default candle holder with lit candles seemed to cause the problem. When I switched it with other light sources at the same position, the light bleeding went away (at least a big portion of it iirc). Try switching that candle holder, I think it might have strange properties.

Out of curiosity: can you please post the entity class of the candle/candle holder which causes your problem? I just checked an old map version before switching it, I think the entity causing my problem was: atdm:sconce_2candles_rigid

Edited March 29, 2021 by OGDA

[Frost_Salamander]

1 hour ago, OGDA said:

@Frost_Salamander

I had a problem like that in "A Night Of Loot" where the candles at the stairs to the second floor where shining up into the attic, despite several brushes and visportals being in the way. In that case it turned out, that a specific default candle holder with lit candles seemed to cause the problem. When I switched it with other light sources at the same position, the light bleeding went away (at least a big portion of it iirc). Try switching that candle holder, I think it might have strange properties.

Out of curiosity: can you please post the entity class of the candle/candle holder which causes your problem? I just checked an old map version before switching it, I think the entity causing my problem was: atdm:sconce_2candles_rigid

I'll check tonight and let you know, as it's still in my mission because I couldn't figure out how to get rid of the problem.  It's one of the basic candles in the holder with the ring on it.

[Obsttorte]

I haven't continued working on that map and never really investigated the issue. idTech4 can be pretty buggy sometimes. Light bleeding is only one known issue. Another is visportals that don't work if lined up with other visportals (they then act like portal_sky instead). I am not even sure whether all instances of light bleeding through world geometry have the same root or whether there are several possibles sources of that issue.

[Frost_Salamander]

@OGDAthe name of the candle entity I had the light issue with 'atdm:moveable_holder_small_plus_candle2'

[HMart]

Perhaps is not this at all but just in case, if you don't know, lights have a light_center, from where light is "cast", for point lights it is normally (0, 0, 0) meaning at the center of the light entity, relative to the light entity "space".  In DR for point lights, afaik you cannot edit this origin, in the 3D or 2D views but you can do it, in the entity tab using the spawnargs, so perhaps, someone changed the light_center from (0, 0, 0), if is even a point light, to something else or created the light programmatically, so again perhaps the light_center, is not at the normal light origin but far away and poking into the other room?

Edited March 29, 2021 by HMart

[Obsttorte]

When I had the issue in the past it was caused by the flame lights def_attached to torches. The only thing I changed back then was to decrease the light radius. The light center gets manipulated for flame lights, but not in such a manner or to that amount. Additionally, it would clearly look different if the light center would be in your room then in another room and bleeding into yours. Pretty distinguishable.

[JackFarmer]

@Frost_Salamander@Obsttorte@OGDA@HMart

 

Not sure whether I fully understand the problem.

However, Dragofer provided me with the following property/values for the lights when I had the same problem with electric lamps in HHTLC:

"areaLock" "origin" -> ties the entity's visibility to the visleaf in which the origin lies

"areaLock" "center" -> ties the entity's visibility to the visleaf in which the center of its dimensions lies

Might come in handy.

[Frost_Salamander]

Hmm I had a screenshot from one of the beta testers for feedback, but they appear to have removed the image from their Google drive.  Basically the issue is light bleeding through brushes when a portal opens.  That is, the light rays reaching places they shouldn't.

Dragofer mentioned those properties to me for the other problem I'm having with models showing up in the wrong visleaf (with showtris = 2), but I tried it and it didn't help.  I think @Obsttorte is right though and that's due to the bounding box.

@JackFarmer what was the exact problem you had that these properties solved for you?

[JackFarmer]

@Frost_Salamander

I had lights leaking through massive walls and ceilings. With the commmands above I could limit them to the areas they were in.

[Frost_Salamander]

4 minutes ago, JackFarmer said:

@Frost_Salamander

I had lights leaking through massive walls and ceilings. With the commmands above I could limit them to the areas they were in.

OK cool - were portals involved?  In my case, the light didn't leak unless a portal was opened (a window).

[JackFarmer]

@Frost_Salamander

 

I am not sure anymore, but I am afraid this only works when the portals are closed.

You should give it a try and see how it works for you.

[Obsttorte]

Light bleeding for me only occoured when portals open. I think the main reason are probably the portals, not the lights or the way the shadows are calculated. Portals can cause a lot of graphical glitches from my experience, although I never got an idea why.

@JackFarmerThose area lock spawnargs look interesting. However, normally one don't want to limit a light to one visleaf. The light should be cast through doors and windows once they are open, shouldn't it?!

[JackFarmer]

16 minutes ago, Obsttorte said:

 

@JackFarmerThose area lock spawnargs look interesting. However, normally one don't want to limit a light to one visleaf. The light should be cast through doors and windows once they are open, shouldn't it?!

I think that depends on the layout.

In the image below, I had a lamp light leaking through the wall from the other side of the door in the top left corner. With the spawnarg I could prevent that, but as you can see, there is also a small maintenance tunnel below the grating without a door and thus the VP always stays open creating weird light effects,

Edited March 30, 2021 by JackFarmer

[Obsttorte]

Are those visportals on the same plane? Did you try shifting the vp in the maintainance tunnel a bit? From my experience the engine sometimes has problems differentiating vp's that are coplanar.

[JackFarmer]

1 hour ago, Obsttorte said:

Are those visportals on the same plane? Did you try shifting the vp in the maintainance tunnel a bit? From my experience the engine sometimes has problems differentiating vp's that are coplanar.

I will check and, if as you say, will try to shift that. Will report back asap.

[JackFarmer]

Update: the VPs are not on the samep plane. Shifted it even a bit more, no positive effect.

[Wellingtoncrab]

Hey Obsttorte - sorry to bother you as I know these scripts were written a long time ago, but I was hoping you might be willing to impart some guidance on a humble mapper. I have been working on a mission with your Hitman style script and your Shop script and I can't quite get the "allowFrob" spawnarg, which allows items to be picked up without witnessing AI going hostile, to work in some instances. Specifically with player tools, weapons and in game shop items.

At first I was only trying to get this to work with the in game shop items using your shop script - which at first made total sense to me why it might be an issue as you can apply "allowFrob" to the shopitem itself, but the script subsequently spawns another item which is actually added to the players inventory which doesn't have the spawnarg at all. So for a while I was simply trying to modify the script to apply the spawnarg to the entity sent to player inventory at spawn, but was finding this was not working either.

So I stuck a "sys.println(m_last_frobbed.getFloatKey("allowFrob"));" line into "hasStolen" check in the observer script and went around trying to figure out where I had gone astray.

It seems like with most "tools" and "weapons" entities: health potions, arrows, player equipment like the black jack, etc they will register the "allowFrob" spawnarg correctly as set in the editor when highlighted, but when actually frobbed and added to inventory they seem to always return a "0" - ie not allowed- and it seems like maybe this is what is triggering nearby AI to go hostile.

Seems to not apply to loot items, moveables, readables, etc. 

So I wonder if these player tool and weapons items are just handled in a way where the allowFrob spawnarg applied to in game entity (for example "atdm:weapon_blackjack") would not actually apply to whatever is actually added to the player inventory? If I wanted to alter the script to accommodate this do you think it is even possible?

 

 

[datiswous]

-

Edited February 2, 2023 by datiswous
I hate to reread this nonsense

[Obsttorte]

As per request of @Dragofer I've updated the shader work from this post.

 

The image manipulation takes place in the fragment shader gl_overlay.fs and can be tweaked as needed. I haven't found a way to pass arguments via the gui to the material to allow on the fly alterations, so the effect is static.

gl_overlay.pk4