Share this post

Link to post

Share on other sites

Yeah I can’t get it to work. Was hoping someone would be able to get me a simple example of either making a stream or just adding to a stream before its sent and receiving it. Tried several different ways and can’t get anything to work even in the rare cases that I can write what I’m told without error it just wont do anything.

Share this post

Link to post

Share on other sites

Thanks a bunch cmac you lead me to the solution. This video explains it wonderfully for anyone else who would like to know how to add data to the stream.

Kinda weird how you have to drag the script from a component to make it observable; didn't find a way to just do it manually through the control as it only allows me to select a gameobject and by default it's transform.

Similar Content

I'm doing a test quest.
The player gets a quest from an NPC to bring him fish.

Once the player picks up the fish, the original NPC gets replaced by a new one with a new conversation trigger. The NPC tells the Player "Well done" and should give 200xp.

The script tells the xp counter to go up by making a reference to the gameobject that holds the text component

But it throws this error:

I'm aware that the error may hide in plain sight. I just have to sort this out, since I'm writing the AI at the same time, and the time it takes to resolve everyone of these errors is tremendous.
Plus, I think I'll learn something. I've been having trouble with some basic functionalities recently. There might be something wrong with my understanding on how programming works.

Glad if someone could help (:

Edit: I'm fully aware that the update function requires an input. I call the function in the editor when the dialogue ends, it still doesn't work.

Hi fellow game devs,
With the help of @CombatWombat in my previous post about clutch modeling, I now have a solid direction for the modeling the clutch. The way I'm doing it is having 2 clutch states: locked and unlocked. EngineRPM and torque will be calculated separately in each state. My problem right now is the logic and code for specifying locking and unlocking.
The condition for locking is when (engineSpeed - drivetrainSpeed) in previous update cross zero (different sign) with the current update (to determine if engineSpeed = drivetrainSpeed or not in-between updates) and engineTorque <= clutchTorque.
The condition for unlocking is when engineTorque > clutchTorque.
The diagram looks roughly like this (taken from matlab website with the similar implementation):

However, the 2 conditions are triggers for switching states, not for determine the current state to be in, so in the end my clutch state just jumped around. I don't have a lot of experience in doing state machine, so can some one give me rough code of how to implement this? Below is my rough code:
speedError = engineSpeed - drivetrainSpeed;
if ((Math.Sign(speedError) != Math.Sign(deltaW) && currentTotalEngineTorque <= clutchReactTorque))
{
clutchLocked = true;
}
else clutchLocked = false;
deltaW = speedError;
//end of update
I think the main struggle is the cross zero. Because cross zero is the "trigger condition" to check if the clutch should lock when it is slipping, not the condition for continuous locking, while the code I have above is the "continuous condition" saying "this condition is true then it is locked/unlocked". Another word, if the clutch is slipping, the condition above would decide if it's locked or not, but once it is locked, the cross zero condition is not true anymore (since speedError and deltaW have same sign as engineSpeed == drivetrainSpeed when clutch is locked). I'm sorry that I cannot explain this better as English is not my first language.

I need help on a script. I am recreating a scene from A Hat In Time where Hat Girl goes into Queen Vanessa's manor. She has to collect keys and avoid Queen Vanessa. How would I script the door where you can open it and peek through it without actually going out the door? Any help is appreciated. Thanks!

EDIT: Not peeking throught the keyhole, just poke your head out the door

So I am building a survival / roguelike? (not sure of the "real" definition of that but the game has perma-death, randomly / procedurally generated worlds, etc.) and I am starting to prototype item decay. Let me example how the turn based system is currently simulated as that is probably important for this discussion.
The way the turn based simulation works is there is a singleton GameActionManager object that keeps track of the action units that have pasted since the being of the game. 1 action unit = 1 second in the game and generally this is progressed from the the player performing an action. When the player does anything that has an action unit cost associated with it, it calls a method on the GameActionManager to increase the current action units. The other things the GameActionManager exposes are methods to register / unregister "event listeners" (currently using delegates). When the GameActionManager increases the action units, it notifies all of these listeners so the can perform the right action (like a burning tile decreasing the health of the structure that is burning, an enemy can move toward or attack something, etc.).
I am also only simulating a small portion of the world at a given time since well, the world eventually will be huge and well computers can only do so much. My current goal for the simulated area is 120 x 80 tiles (with is a total of 9600 tiles). So as the player moves, game entities (enemies, structures, items, etc.) come in and out of the simulation area (and register / unregister with the GameActionManager). With this size in mind, none of the things that currently attach listeners to the GameActionManager has the chance of getting big enough to have me think that I really need to think about an alternative solution for when it becomes an issue because I don't see it becoming an issue any time soon (at least at the current stage of development). Items however is a different story.
The game is going to have a ton of different items and 1 or more items can be on any tile. If each tile averaged 2.5 items (which I will grant you seem ridiculous but I always think crazy extremes when it comes to this kind of thing), that would be close for 25000 items that would possible have to manage decay. So instead of having each item attach a "listener", since the action for managing decay is going to be exactly the same thing for each item (just a method call), I figured having 1 listener that knows about all the items would be better.
The general approach that I am taking for this first prototype is to have a singleton manager class (lets call it ItemDecayManager). Any time a item that has decay come into the simulated area, it would register itself with the manager and when it leaves the simulated area, it would unregister itself (which would just add and remove itself from a private List the manager is maintaining). Any time the action units are increased, the ItemDecayManager's listener on the would fire and just loop through the List of registered item and just perform the required function call.
I have done some crude benchmarking and it currently can handle 100000 items at which point it starts to have a little effect on the FPS (but still around 80) even when moving about 15 times per second (and each move causes an action unit increase). Also bear in mind these numbers of from running the game in the Unity editor which has a bit of extra overhead that running the real game build not not have.
While I am going to run with this solution for now I want to throw out this idea and get any kind of feedback i can because I imagine when more is happen as the action units increase (and even imagining the process for managing decay become more even just slight more complex than the current simple calculation), this solution might not hold up and I would like to have so ideas ready for the situations. I also think of anything that is going to be simulation, this is going to be the first things to have issues from the shear number of items that could be in the simulation area.
Thanks in advance for any and all comments.