Hmmm... Placing blocks on default gam terrain is disabled and hiting items is possible so that cause to kill it

I finally had some time to have a quick look at your mod.

from what I can tell it looks pretty nice for the beginning but I saw some things which can be improved:

use the command texture in the on:hit event to give the blocks some cracks while hitting them, just like in the real minecraft game. helps to see how much longer you have to keep hitting the block.

in your 3d modeling program put the block up so it starts at y=0 and not below. this way blocks wont "fall down" half a block when they are destroyed.

use units instead of items for the collectable blocks so you can give them an animation that will make them rotate slowly. pretty much the easiest animation possible. also dont forget that you can use the same model with the animation for the object as well, so dont create 2 files!
all you need to do is write 2 definitions for it.

optimize your scripts!
e.g. you can remove this part from ALL of the blocks (btw the indention isnt great here):

instead you can simply use a loop on:load in the game.inf file.
use the "count" parameter to iterate through a row of numbers with the last one as large as the amount of blocks you have.
for the on:kill part you can simply replace the 40 in this example with type and put it into the same script that is called in the extendscript command above.


in the view_ckeck.s2s file there's a major error as you only use "=" instead of "==" in the comparison. I'm suprised this doesnt trigger an instant script error or something...

next there is anoter giant problem with the script optimization:

this is only a small part but as you can clearly tell there is a lot of repetition going on here, as well as wrong use of the if command as you dont even use elseif here
I've seen this in roughly 20-30 places now where you never use "elseif" but always a new "if".

to help you try get a better understanding of if/elseif:
when the if-part is triggered all following elseif-parts are ignored which is what you want because it's faster.
when the if-part is false it will be ignored and the next elseif-part will be activated, checked and triggered in case it is true. then again all following elseifs are ignored.
what you are doing is to start an if-part and end it again, then start another one and another and another. this way they all have to be activated and checked and declined when they are false which is obviously the case when already another if-part was triggered earlier.

in fact the code is that much un-uptimized that my fingers start itching when I see it because it's screaming "FIX ME!" into my face but sadly I dont have the time to get into this atm because of exams start in a month or so and I'd even say it'd be faster for me to write the code from scratch than having to read and understand all of your code

another example:

why IN THE WORLD would you use the exists command here?!
when you can HIT an object, it's pretty much obvious that it exists, otherwise you couldnt hit it, right?!


also, normally you never ever have to use the freevar command:

this variable isnt even used in this event, why would you use it here?!

Edit:
I had another look at the gameplay itself and what I can say is that the block placing fells rather wonky. I do recommend to do as I told you before: split each block into 6 different objects.
this way it would be way easier to detect which block the player aims at so a newly placed block is really placed at the right position.

also I recommand to make a complete list (as far as this is possible) of different block types that you want to put into the mod in order to prevent chaos later on due to the lack of planning ahead.

Thanks



I use "exists" command because when kill object without this, game cause a bug

rather suspicious.

to be honest I think the problem has to be somewhere else then because this command doesnt really make any sense there.

Of course, everything is in-dev

EDIT: I have problem. I wanna to make torch drop when block attached to it is broken using loop command, but I have big problem how to start. Can somebody help me ??

you should better make an event which updates the 6 neighbors of a block, depending on whether the center block was just created or removed.

with inrange command ?

Edit: also I have problem with placing block in block. I try inrange command but it don't work ;/

I have come to notice this a couple of times now so I want to suggest that when updating the first post of the thread you should also either put a date above the new changes and/or ALSO put the changes into a post at the end of the thread.

Its a bad copy of minecraft..
Sucks.. Be creative for gods sake..

Genius...

@ Hurri04: Yes, I add video record date And this video sucks I will make better when I get better recording program and fix bugs

CAN'T WAIT TO TRY IT :D... Thank you man!

Thanks! It's hard to make it alone ;/ but thanks for advice

Thank you for the new version! Keep on your work.

I just downloaded the latest version and tried it out again a little.

from the playability-side there are still a few flaws, mainly that blocks can be placed in other blocks and the rather strange behaviour when placing blocks in general, as I already mentioned in my comment to your video.

the next thing of course is that Stranded 2 isnt really meant to deal with such an amount of object that would be needed to generate real landscapes like in minecraft. I hope that S3 will be better with handling massive amounts of objects. maybe you should jump into the IRC chat and bug DC a little to make sure he keeps focussed on working at the new game


I also had a look at the scripting side and here I must say that I see way too many scripts for my taste that could and should be better optimised. the definitions still have parts that are completely equal, like that extendscript in "on:create" which could simply be put into a loop in the game.inf file to run through all types which need it. "on:preload" should do the job.

also, the exists stuff is still unnecessary in my eyes since the "on:create" event cant be triggered at an item if it doesnt exist.

the "on:inhand" event can be done in a better way. there are only 2 variables which are set to be used in another script.
the first one can be replaced by using getplayerweapon in the script which uses this value and the second one could also be done in this script by using extract to use the previously received value to return the type out of a string line which contains e.g. "TYPE1:TYPE2:TYPE3" and so on.

last but not least, the game_placing.inf file which contains the script part with pitch and yaw you talked about in the comments to the video:
you always only use 90° angles, rotates by 45°. but you doint really consider that the player can also look from different angles.
take a look at this (professionally drawn ) picture:

the red arrow shows that the player wants to place a block above the one the arrow is pointing onto. but instead because of the way you scripted it only the pitch and yaw angles are used to calculate the direction the player looks, so the new block is places at the side of the block which the extended arrow points to. this happens when the player looks up for more than 45° from straight down and is the reason why blocks can be placed in other blocks as well as the aforementioned "wonky" block placing.

for this reason I highly suggest that you split blocks into their 6 sides, as I already said in the video comments.


other than that there are more things in the script which could be imprived but unfortunately I think those are too many and too small for me to list them all here, which would also be rather time-consuming for me.

my advice would be to try such a mod in S3 once it comes out. it's rather difficult for someone else to try and read themselves into someone else's code and I think it might be easier to start most of the scripts new from scratch.

Allready fixed by freespace command

I will upload a 0.2_2 fix version and after that I'm going to make split block to 6-sides but I have some problems because I want to make one side polygon and create other and rotate them like "$side1, $side2" etc. and placing will be by getting it rotate etc. (ehh. not to clear reply ;/ )

no, dont even try anything with rotation via script commands.

it's better to make 6 separate models in which the sides already face the right way. this is less work with scripting and you have the advantage that it is easier to make blocks which look different on each side if it's necessary.

also the way the solution I told you about relies on this as each side gets its own object type. this way each side, no metter which block type, can inherit the same events by using the extendscript command.

this means when you rightclick the top side of a block you only need to write a script into "on:use" which checks the current position of the flag info around which the 6 sides are placed, then adds the height of a block to the varibale in which the current height-position is stored, check for flag infos in that area by looping through them (there should be only one) and then create the 6 sides of the new block at that info.
to optimise the performance you might want to delete the sides which are now facing each other or dont even create that one of the new block at the first place but still delete the one of the old block.
finally trigger an "update" event at all blocks surrounding the new block (up, down, left, right, front, behind).

6 models= + 6 more IDs ! Anyway I'm uploading now 0.2_2 and I getting to work on 0.3

Also I will be glad if I will get Super User for my hard work ..

and...? besides the facts that you mean type-numbers instead of IDs and that it's only +5 instead of +6, what does it mean if you have to use 6 types instead of 1? even if you had to use 10, there are still enough numbers left, you just have to use such one that are a little bigger. there is absolutely no problem with that.

and I think it takes a little more to get super user, I for instance helped other people with questions relating Stranded 2 scripting in both the english and german section for years!
other than that, I got the mode because my mod was so big that I wasnt able to upload it here on unrealsoftware anymore. the super user mode now grants me 3 times the space when uploading but apart from that there really isnt much of an advantage...

Or I can convert AABB to 6-sides and crating will be from it of course I will optimize timer of it etc. (or use other way to update position of it)

very neat mod dude...pretty dam blocky

Hurri04 has some very important feedback, you should take heed to what he is saying cuz he knows exactly what he's talking about bro. "Make a 6 sided block bro if it solves alot of problems." Sometimes the very hard work of making something that is difficult...can payoff ten fold.

You could even name the ID's to make it simple...like sidetop,sidebottom,sidefront,sideback,sideleft,sideright. So you always know what ID is referring to what side, in any script.

Adding 6 ID's is nothing...really it is NOTHING! My mod has hundreds upon hundreds of ID....what is 6 to solve some issues you can not solve otherwise? I added a Cornstalk as a food item of corn and it took 2 cornstalk models 2 cob models and a cooked corn model, adding 5 ID just to add 1 basic food. If 6 sided block with 6 ID would improve performance and fix bugs DO IT BRO!

To make ID tracking easy you can open notepad and make a list of ID and names for reference. Put it right in your sys\ folder for easy access. Makes it easy to keep track of ID and find ones you need to reference when demanded.