Flexman

Yes I wondered about this when I saw the road video demo on a popular video sharing site It was on my list of nice things to have. So, I flag myself as another user who would use this feature.

Well..hmm. It's certainly a tablet in the sense of form factor. Once I got over giggling about the name (jokes about feminine hygiene products and incontinence pads are beginning to snowball) I can see it being very useful as a thin client for web based applications. I developed program used in ASDA/Walmat for day to day operations, one of the big problems using it is the daily process going around a store or warehouse gathering data. And such a device would be handy for that and more but bloody expensive atm. It's a consumer device (for consuming content). Delivery of movies, books, apps and games. Lot of people just want that. I think the unintended consequence will be an explosion of the language of machine interaction through touch. As ubiquitous as the mouse is today, it's use will become second nature, even trivial. I was reminded the other day that eighty percent of the jobs that will be around when my children reach adulthood, haven't been invented yet. Touch has spreading slowly, quite often in the history of technology something happens that nobody expected really kicks it off. I suspect we haven't seen that yet and this is only the beginning. But what bugs me about devices like this and this happened with the Kindle too, is the prediction that they mark the end of traditional printed books. I can take my old fashioned, well thumbed and yes, heavy books on a long plane flight to Hong Kong but it won't run out of power mid flight. I can loan my latest Neil Stephenson doorstop to someone without any DRM issues. We can discuss it afterwards, even write in the margins. There is a department in the British Library devoted to the cataloging and study of margin notes in books going back as far as the 16th century. They tell a rich history of the time the books were printed, the people who read them, they lend character to those books. It's not just the book itself but it's place within time and the people it touched. My (now ex) wife sold her first edition Terry Pratchet Colour of Magic (she typeset it). With the hand written notes and dedication for her diligent work on the material it stands out. Sadly poverty required it to be sold on ebay for nearly four grand. To suggest that books are only meant to be read is admitting they don't understand the nature of books and how people relate to them, and such predictions coming from Amazon beggars belief. These devices are sterile, passive delivery systems. A BBC reporter described the iPad as a giant iPhone ("HELLO?? YEAH?? I'M IN A BOOKSHOP"). So it's not so much the hardware that's important but the infrastructure. AND you can't stick it in your pocket, sit down and crack the screen. All of the above is of course IMHO and clearly the deranged ramblings of someone who really doesn't care but didn't have anything else better to do but write all this ****. Now where is that Ed Macy book I was reading? p.s. It just occurred to me that the quoted 10 hour battery life (which seems too good to be true) is perhaps best case scenario. Although, once the battery does run out the iPad handily converts into the iTray.

Ahhh, Gregorian New Years Day again. Another year gone but no wiser I fear. As a boy, I remember thinking I'd never live to see 2010. As a girl ... onm. I sincerely wish you all success with your programming endeavours this year.

On a slightly different note, someone made a 70 minute review of The Phantom Menace which was collated at Slashfilm (see link). It contains strong language but has well structured arguments.

I added the camera icon to downloads here.

File Name: Camera Node Icon for LE 2.3 File Submitter: Flexman File Submitted: 18 Dec 2009 File Category: Materials Resolution: 64x64 Place this DDS icon file with the "info_camera_node.gmf" file, normally located at ...\Leadwerks Engine SDK\Models\Entities\Info\CameraPath\Node This will show the camera position allowing you to link camera nodes together (for paths). To do this click on a camera node, then drag the mouse and release it on another camera node. This should create a link, turn on "helpers". Click here to download this file

Yes I was watching that news story on the BBC today. It's a highly technical and competent film. I can never get enough of giant robots stomping on things. Unless it's another bloody Ironman movie...or Transformers....or GoBots...his 4 min movie was better than all of them combined IMO.

I think the engine is optimised in such a way that you can't do that. As you say you'd have to reconstruct the surface. Without knowing what it is you want to do this suggestion might be useless; can you use "findchild" on the mesh? If iit's a child you can use EntityColor on it (but you probably know that already). Create surface and copy from existing one would be your best bet then.

Yes, to confirm, any children will also be destroyed it when base_Kill iterates through the model. *gulp*

Bit of a gimmick anyway IMO. Been here before, twice already. 20 years ago, then 1996 with 3Dfx. Since nVidia bought 3Dfx I bet this is just the same old stuff wheeled out on the back of the current 3D movie trend and will have as much legs as it did back then. Problem is...human physiology hasn't changed much in that time. Trade shows are great for selling this technology where you don't get to use them for very long, I'm sure some of us know what it's like at these things. You know, you've tried it. Translate the experience to the home or studio and it's headaches and eye-strain. The older you are the worse it is. Today software built into stero cameras and rendering suites try to minimise this by smart clamping of field depths and some other techniques but it's not that great a solution. You're still looking at a fixed distance and forcing the muscles in your eye to move. To get used to them for long periods you need the discipline of an Apache helicopter pilot, wear the thing, don't complain lest you get removed from the flight roster, suffer the migrains and after a few weeks the headaches stop. Until you take a long break and come back then the cycle repeats. Some young folks seem to be able to handle it without problem. I predict it'll be nothing more than old news this time next year. It's a pitty, as I got really excited the first time I tried it and it really does make 3D cockpits really "pop" but it's just uncomfortable. Stick with head-tracking like Naturalpoints' TrackIR or FreeTrac, it's less intrusive and works with LE and just about anything else.

I don't think Newton has repulsive forces. But maybe can be simulated. This is off the top of my head but I would tackle Mk1 like this... Using something like ForEachEntityInAABBDo and give your mine a key that specifies the size of the AABB bounding box (this would be the area of effect). From what I understand, when the mine detonates you want to apply a force to all bodies within that volume around the mine. The amount of force would be distance from the mine entity (with some falloff factor). And supply AddBodyForce with the vector from the ship to the mine (see TFormVector) and your calculated explosive force. Other ideas anyone?

If you want a list of exposed commands, use Tylers Debug LIbrary in the downloads section. And in your code use the "LogGlobals" command at the top of a script which dumps all ... well Globals. Functions and constants alike. Cut and paste the output into something like Notepad++ which can sort text into alphabetical order (select all > TextFX_Tools > Sort_Lines ). And you have an alphabetised list of (a lot of constants but also) functions. Doesn't give detail on parameters but it's enough to confirm the existance of a command. Easy to spot the omissions.

Well....hmmm...I'm using a 4096 res map @ 10m per tile. I'm happy with the way things are. If I wanted to populate such a map with objects, without a good culling, grouping system it wouldn't be practical, a map would takes ages to load. After chatting with a couple of very nice members of the LE community the consensus was that if there's anything really needed, it's not more features, just a few fixes, examples and documentation. Documentation, documentation, documentation. Take the whole Corona thing for example, people were trying to get them working and failing until Josh stepped up and said you don't do it like that any more, do it like this. I'd love more info on vegetation data, most of my terrain is empty desert, most features are already stored as GIS data which I want to import at some point. Certainly don't want to hand-paint it all, that would take ages. As for little fixes, well....vehicles, give them brakes and or the ability to make them active/inactive. Racing games are perhaps the easiest and cheesiest to produce on a new engine and it would be easy to make one in LE now there are roads and vehicles. But it would be an incentive if you could populate your starting line with vehicles that didn't roll off the track at the start. Josh is very capable and he'll get it sorted in time I'm sure.

Just Cause 2 is looking really impressive with that huge open world, weather systems and cool black para-glider McGuffin. Again, another highly specialised engine. I think the Playstation 3 really excels at that kind of streaming. I'm still impressed with Grand Theft Auto on the PSP.

The flashlight in the demo used "PaintEntity()" on a spotlight to apply a texture in a similar manner. In the Leadwerks Editor, create a spotlight and assign the material to it. example from flashlight.mat texture0="abstract::flashlight.dds" blend=LIGHT depthmask=0 castshadows=0 lighting=0 shader="abstract::mesh_diffuse.vert","abstract::mesh_diffuse.frag"

This is something I've been having not much fun with. As I'm using BlitzMax, the cross platform FreeJoy input module doesn't work too well with exotic input devices, like SDL, the joystick polling relies on Winmm calls which only supports a maximum of six axis. They don't support all the options you might get on fancy flight stick (e.g Saitek X52). Also XInput only supports a subset of axis which again is no good if you're wanting to cover all bases (plus the source I was looking suggests it supports 4 input devices max?). DirectInput seems to support everything including the exotic 3DConnection SpaceNagivator (which blew me away as normally it's a desk weight outside of Google Earth and Max2009). I'm just not having much fun transposing DirectInput C++ code into a manageable BlitzMax mod atm. Something is wrong with my pointer to DI interface or something. Maybe I'll start a thread in the BMax programming forum, maybe some of you geniuses can see a better way.

Well, hardware and aesthetics aside, pricing is complex issue that goes beyond what you see is what you buy. Apple has always been about asthetics. I've worked in high-end publishing (books, advertising) where Apple dominates in the same way as their 'rivals' dominate the domestic market. They know their audience and it's strengths. It's a different world. Nothing to do with brain-cells or lack-of. Just business. I'd love a new mac-book for doing that sort of thing, it's the computing equiv of a low emissions car.

File Name: beacontower.lua File Submitter: Flexman File Submitted: 10 Dec 2009 File Category: Lua Scripts This LUA code is used with one of the Dexsoft radio tower models (from their industrial packs). It adds three lights and makes the top one blink at a specified interval (in millisecs) and colour. Can be used with any model, you'll have to edit to position the three corona locations by hand. And it's easy enough to add or remove corona. Click here to download this file

Maybe paste it into a different editor? I highly recommend Notepad++ from http://notepad-plus.sourceforge.net/uk/site.htm Small footprint, versatile and free. Never had a problem pasting code. But what I will do, is make the above code available as a download in the...downloads...section.

This LUA code is used with one of the Dexsoft radio tower models. It adds three lights and makes the top one blink at a specified interval and colour. But the view range isn't all that great. I was going to ask for suggestions for setting the Corona view range as I tried Lua: entity:SetViewRange( near, far, recursive ) as per the Wiki but only got an error. However the following worked: EntityViewRange(entity.antennalight[i],800,1000) Here's the full script if interested. dofile("Scripts/base.lua") function InitDialog(grid) base_InitDialog(grid) --custom properties group=grid:AddGroup( "Beacon" ) group:AddProperty( "blinkspeed",PROPERTY_INTEGER,1000,"Blink Speed") group:AddProperty("beaconcolor",PROPERTY_COLOR,"","Beacon Color") group:Expand(1) end function Spawn(model) local entity=base_Spawn(model) entity.antennalight={} entity.blinkspeed = tonumber(model:GetKey("blinkspeed","1000")) entity.beaconcolor = Vec4(1.0,0,0,1) entity.lasttime = AppTime() entity.blinktoggle = 1 for i=0,2 do entity.antennalight[i] = CreateCorona(model) entity.antennalight[i]:Paint(LoadMaterial("abstract::flare1.mat"),1) entity.antennalight[i]:SetParent(model,0) entity.antennalight[i]:SetColor(entity.beaconcolor,0) SetCoronaRadius(entity.antennalight[i],1,1) EntityViewRange(entity.antennalight[i],800,1000) end -- Fixed light positions on our antenna entity.antennalight[0]:SetPosition(Vec3(0,35,0.1),0) entity.antennalight[1]:SetPosition(Vec3(1.5,25.2,0.1),0) entity.antennalight[2]:SetPosition(Vec3(-1.5,25.2,0.1),0) base_SetKey("collisiontype",COLLISION_PROP) --An update function for one instance. Declaring the function as part of the entity table allows us to use "self" for the table function entity:Update() if (AppTime()-self.lasttime>entity.blinkspeed) then self.lasttime = AppTime() self.blinktoggle = -self.blinktoggle if (self.blinktoggle>0) then self.antennalight[0]:Hide() else self.antennalight[0]:Show() end end end end function SetKey(model, key, value) local entity=entitytable[model] if entity==nil then return 1 end if entity.model==nil then return 1 end if key=="blinkspeed" then entity.blinkspeed = tonumber(value) elseif key=="beaconcolor" then entity.beaconcolor=StringToColor(value) entity.beaconcolor.w = 1 entity.antennalight[0]:SetColor(entity.beaconcolor,0) entity.antennalight[1]:SetColor(entity.beaconcolor,0) entity.antennalight[2]:SetColor(entity.beaconcolor,0) end return 1 end --Update function, called during every UpdateWorld() function Update(world) if world==world_main then local model,entity for model,entity in pairs(entitytable) do if model.world==world then entity:Update() end end end end

Looking good

Scene: Skies high above an island, tumbling over and over, ground, sky, clouds. Rapidly spinning. Sounds of wind, a thumping heartbeat. Glimpse of an aircraft in flames breaking up in the process of crashing into the sea. Plummeting through clouds. You hear other peoples screams around you, other passengers? You remember you were on a plane, being served drinks, now you're falling to certain death, but the graphics look really great. The ground only seconds away. Impact. Black screen. (that's how I would have ended Lost in episode one. Good riddance.) How about...you wake up one morning, a bedroom, sunlight streams through a window (godrays turned on). But here's the twist. You find yourself transformed into a giant insect. No, no, that's a terrible idea. OK, you're a moisture farmer out in the desert, a tornado comes so you seek refuge inside your house but it's swept away and your transported as if by magic onto a space station inhabited by small people ruled by fear. Fear of an evil wizard. And only your knowledge of advanced weaponry (and moisture farming) can save them. No, too many assets required, but otherwise a great idea (note to self: another one for Lucas). A tree, in a forest, camera plays around it, it's an apple tree. Comes to look at one apple, the wind is blowing. The apple falls. Camera tracks the apple but time is slowing down. The apple falls slower, and slower. The apple never reaches the ground, it just hangs in the air, some other apples fall but they all hit the ground. Our apple doesn't. It's a special apple, ripe and juicy. OK, it's an allegory of the human condition. Particle physics. Sub-atomics (my fav). Scene: A conversation between two particles as they whizz around a large accelerator. One talks loudly about where he went on holiday, the other is bored, disinterested, constantly plagued with doubt and uncertainty, especially about where he is at any given moment in time. Everytime the loud one glances at him he jumps to a random position. See, it's educational. They both end up splatting into mirror images of themselves (but lady particles) and the resulting explosion of energy produces lots of little versions of themselves that flood the target chamber. Awwww. Well I'm out of sensible ideas.

And dont do what I did, plug a USB cable into the Firewire header "Hey this mouse is broken, I'll try this one...hmmm, this mouse is broken too, what about this one....hey, all these mice are broken...what are the odds of .... uh oh." (different voltages, stupid m/b had same pin layout for each).

To be realistic you need to move the world around the sun ( little joke - of course it looks the same, people see what their knowledge tells them they are seeing ) I'm impressed by earlier efforts to make day-night cycles. I think they used a colour table for the time of day and set the sun entity (directional light) and ambient colour to some factor. Other points I noted: The directional light should fade to nothing before reaching the horizon as shadows are not that strong in low light conditions. Ambient light takes over from directional light at sunset (and vice versa at sunrise). Some used a fading skybox to show stars. Pre-computed light scattering colours would be faster. I did some work on planet atmospheric shells and calculating the light scattered through them many years ago, think it was called Rayleigh scattering. (edit) I just found a useful link GameDev - Atmospheric Scattering

Aha, yes. To confirm, that works now. Serves me right for trying to be cleaver. It's no hardship to set it to a fixed size. I'm guessing the AABB isn't updated until a scene update which occurs in the editor environment but not when it's loading for the first time in a compiled app. That's a beer I owe you. Cheers.