I'm curious about the differences between misc_textbook and misc_textstory,, specifically what makes them different, and what functionality they have in the way they display text (i.e. can they align text to a left or right margin).
If there are any source map files that show off these entities and what they can do, I'd love to know!
 
misc_textbook is literally a book on pedestal. While misc_textstory is a part of continuous story made through/with several misc_textbooks. Such a thing is made in Leptis Magna map (source is available), where there are around 20 books and no matter in which order you will find them - texts will show in order. In fact in order to do that you will also need misc_textstoryctrl, it's something like a transporter - transfers texts from set of misc_textstory into set of misc_textbooks. It's really much easier to just look into ad_magna.map. Set of misc_textstory is right above main yard in the skies
PS. Sorry for clumsy Eng. Sometimes it's really hard to me to describe some things
 
Last edited:
As Alex has said, misc_textstory was designed for ad_magna map so that the mapper can tell a complete story, but the player can find the parts/books in any order. It would be frustrating to find books out of order especially for a large story!

Here is a small test map (source included) showing text story entities and the controller which is required to control the whole setup.
 

Attachments

  • test_storybooks.zip
    169.5 KB · Views: 53
Can you change the direction of a func_train using a button? I see in the example maps you can change the speed, but I can't seem to figure out how to reverse the train or have it choose the alt forward path.
 
Can you change the direction of a func_train using a button? I see in the example maps you can change the speed, but I can't seem to figure out how to reverse the train or have it choose the alt forward path.
You can change the direction of a func_train via a trigger but, its not a simple task to setup. Ideally it should of been something easy to implement, but alas it did not turn out that way. So, lets start with the new func_train test map ...

1680537603984.png


Before I get into the nuts and bolts I recommend that func_train entities in AD are lit in separate spaces of the map, so that they have more uniform / consisent lighting. Underneath the main area of the test map are three separate boxes (covered in skip texture) that the func_train entities spawn into and once the map is loaded, they are moved into position (above) ready for use.

The problems of going backwards ...

Func_train entities can start with a REVERSE direction spawnflag, but this is only set once when the map starts and cannot be toggled directly. Another way to switch func_train direction is to use the REVERSE spawnflag on the path_corner entities, but this creates a bounce effect where the train will go back and forth instead of just going forward OR backward. The best solution is to modify the path_corner entities to switch between the two "forward" routes. Unfortunately using the proper backward route does not work correctly because it creates a bouncing loop between two path_corner entities instead. I know this is misleading, but its something that was overlooked at the time. :(

The test map has 3 func_train setups, with the back two (next to the exit teleporter) showing the REVERSE spawnflag options on func_train and path_corner entities and how they are not suitable as a switchable trigger event. These are included in the test map to show how the reverse spawnflag feature works but, they are not relevant for the requested setup.

The correct solution is the first one (directly infront of the player) with a func_train waiting to start with a floor button. Once the train has started moving the right hand wall shoot button is available to toggle the direction of the train, either forward or backward around the small loop.

There are a lot of tricky things going on with this setup, so lets start with what is required first ...

* All the path_corner entities have to use the EXACT spawnflag option, otherwise route switching will not work correctly.
* Every path_corner entity has to be updated via a trigger_relay to switch its route state (forward=1, forward alt=2).
* The path_corner entities need to be all setup to use "target2" keys. This is the fake "backward" route.

The shootable wall button will fire a trigger_relay located in the middle of the train loop area. This relay has the TOGGLE spawnflag enabled and a target/target2 setup defined. This relay will cycle between the target/target2 keys everytime its fired by the func_button. This is the toggle logic (its optional, but it shows the switching of the train direction perfectly)

The middle trigger_relay then fires a further set of trigger_relay entities (this is the core logic and what does the switching) around it that change the exact route direction of the path_corner entities. (if developer 1 is enabled, this switch event is mirrored to the console for debug reasons) This is how to make the train switch between route 1 (forward) and route 2 (forward alt) or vice versa. Every path_corner entity in the chain will need an extra trigger_relay entity to switch between the routes. In the test map you can see the two extra trigger_relay entities above every path_corner entity. (This is for visual reasons, so its easier to know how entities are connected)

Hope that helps, if @madscientist got any more questions, ask away.
 

Attachments

  • test_functrain_rev.zip
    202.3 KB · Views: 49
Thanks so much! This is really helpful.

I had tried using the corner_route key in trigger_relays like you show, but I did not use the EXACT spawnflags for the path_corners.
And I did get the train to reverse using the REVERSE spawnflag, but this is way more intuitive.
 
  • Like
Reactions: sock
I'm trying to figure out how to make a .mdl (misc_model) fade out using AD). I got it to fade in, using the alphastart key. I can't quite figure out how to make it fade away and disappear though. Firetop Mountain (ad_mountain) has the disappearing knight. Nothing special, no movement or anything. Just trying to get a model to fade away upon firing its trigger.

There is no special feature for fading OUT a misc_model, but you can do a map hack if you want to get something similar. I have included a test map (source included) to show what is happening.

I have taken the fading mini shub from "test_misc_model" map and added an extra entity key.

"estate_reset" "RemoveGib"
The case (letter capitalization) is important because Quake C is expecting certain code names. This entity key will call a special function "RemoveGib" when the entity state reset function "estate_reset" is called. To call this function the trigger entity "func_button" has an extra entity key as well.

"estate_trigger" "8"
The wall button "func_button" will trigger a reset function "estate_reset" on the target "misc_model" entity.
 

Attachments

  • test_misc_model_fadeout.zip
    170.4 KB · Views: 47
@sock, one of the playtesters on discord had their game crash by mouse-scrolling up after getting the rocket launcher. Several people suggested it was probably a bug in AD, but I have not been able to recreate it. I have tried the following ports on linux (Manjaro): Quakespasm (v0.95.1), QSS (v2022-08-11), FTEQW (v6202), and vkQuake (v1.22.3). The playtester used Ironwail v0.7 on Windows 10. I have not tried Ironwail because I don't have time to figure out how to compile it. It seems strange to me that it would be an AD bug, but I have very little knowledge about ports and mods. Have you encountered this problem?
 
I have tried the following ports on linux (Manjaro): Quakespasm (v0.95.1), QSS (v2022-08-11), FTEQW (v6202), and vkQuake (v1.22.3). The playtester used Ironwail v0.7 on Windows 10
@madscientist If this was an AD issue then it should affect all engines. To solve this issue then it needs to be something that can be reproduced in a test map like for example "test_custom_hud". This map has all weapons and if there is a crash then it should happen on any map with a RL pickup. If this works then the original playtester needs to find a way to reproduce this issue consistently. Additional information will be required liked; exact version of Ironwail, steps to reproduce and then finally contact the engine coder for extra help.

their game crash by mouse-scrolling up after getting the rocket launcher.
Possible map/AD issues, player only has the RL and no other weapon/ammo to mouse scroll up too. Have you removed the axe/shotgun from the player? Did the player run out of ammo for all weapons and has no axe? Ideally get more info from the playtester about what exactly they did for this crash to happen. Also how did AD/engine crash? crash to desktop? crash to console with error msg?
 
Have you removed the axe/shotgun from the player?
Yes, the map has the player start with nothing.
Did the player run out of ammo for all weapons and has no axe?
I do not think so, I will have to check the demo.
Oh, the playtester did run out of ammo. I did not try that.
Also how did AD/engine crash? crash to desktop? crash to console with error msg?
It looks like it crashed to the console. Attached is the console output from the playtester.

Given the 'running out of ammo'-bit, I will try again to reproduce the crash.
 

Attachments

  • console_2023-04-10_12-49-06.png
    console_2023-04-10_12-49-06.png
    197.4 KB · Views: 56
Yes, the map has the player start with nothing.
That console text is a mod crash report, runaway loop in weapon cycle code. The problem is you have start with no weapons (that means nothing including axe!) and only give a RL which when it runs out of ammo, the code does not know what to do. Quick fix = give the axe just before the RL or at the same time and the code will cycle to the axe (melee) and not crash. Its interesting that Ironwail is so fussy about this and all the other engines just ignore it.
 
  • Like
Reactions: alexUnder Ros
That console text is a mod crash report, runaway loop in weapon cycle code. The problem is you have start with no weapons (that means nothing including axe!) and only give a RL which when it runs out of ammo, the code does not know what to do. Quick fix = give the axe just before the RL or at the same time and the code will cycle to the axe (melee) and not crash. Its interesting that Ironwail is so fussy about this and all the other engines just ignore it.
I am going to use the quick fix, but here is a little more information. I successfully reproduced the crash in all ports I listed. The caveat is that you have to mouse-scroll after you run out of ammo. If you press the fire button before that, the RL disappears from the screen and a mouse-scroll will not produce a crash. Also, pressing the number keys to select a different weapon does not produce a crash, though you can still mouse-scroll afterwards and crash it.
Hope this is helpful.
 
Is there any way to keep the grapple from replacing the axe? I was wanting the axe to be the "collector" for the McGuffin collectibles
Unfortunately the Grapple replaces the Axe because I did not want to implement the grapple as a new selection/activate key. The Grapple hook also has a melee/damage ability so that the player can interact with the environment or knock monsters off ledges!

If you want to have a McGuffin style collectible then use the entity "item_custom" with the mdl key pointing to the Axe model ( regular = 'progs/g_axe.mdl' and shadow = 'progs/g_shadaxe.mdl' ) Once the player picks up the collectible, set a map variable and then query that if you want to change anything in the map.
 
Here is my map for the jam. Please let me know if there are any problems.

UPDATE
Added gold key signs and removed old train path_corners and trigger_relays.
 

Attachments

  • ej3_madscientist.zip
    500.3 KB · Views: 55
Last edited:
  • Like
Reactions: alexUnder Ros